(19) 



J) 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(11) 



EP 1 122 644 A1 



(12) 



EUROPEAN PATENT APPLICATION 



(43) 


Date of publication: 


(51) Int CI7: G06F 9/46 




08.08.2001 Bulletin 2001/32 


(21) 


Application number: 01100135.1 




(22) 


Date of filing: 15.01.2001 




(84) 


Designated Contracting States: 


• Hofman, Ralf 




AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


22142 Hamburg (DE) 




MC NL PTSETR 


• Sommerfeld, Kai 




Designated Extension States: 


OHH>IO 1 1 — i-i-i In ■ mm mm i X~\ C \ 

21149 Hamburg (DE) 




AL LT LV MK RO SI 


• Schulz, Torsten 






25421 Pinneberg (DE) 


(30) 


Priority: 14.01.2000 EP 00100212 


• Eilers, Bernd 




14.01.2000 EP 00100211 


21107 Hamburg (DE) 




14.01.2000 EP 00100740 


• Pfohe, Thomas 




14.01.2000 EP 00100739 


22143 Hamburg (DE) 




14.01.2000 EP 00100738 


• Honnig, Michael 






22143 Hamburg (DE) 


(71) 


Applicant: SUN MICROSYSTEMS, INC. 


• Meyer, Markus 




Palo Alto, California 94303 (US) 


21423 Winsen/Luhe (DE) 


(72) 


Inventors: 


(74) Representative: HOFFMANN - EITLE 


• 


Hutsch, Matthias 


Patent- und Rechtsanwalte 




22111 Hamburg (DE) 


Arabellastrasse 4 






81925 Munchen (DE) 



(54) A method and system for dynamically dispatching function calls from a first execution 
environment to a second execution environment 



(57) A method for enabling a first software program 
using a first binary specification in a first execution en- 
vironment to employ a limited functionality of a second 
software program using a second binary specification in 
a second execution environment first creates a bridge 
in the first execution environment. Using the bridge, a 



proxy wrapping an interface to the limited functionality 
of the second software program in the second execution 
environment is created in the first execution environ- 
ment. The proxy is used to access the limited function- 
ality of the second software program in the second ex- 
ecution environment. 




Printed by Jouve ; 75001 PARIS (FR) 



EP1 122 644 A1 



Description 

BACKGROUND OF THE INVENTION 
5 Field of the Invention 

[0001 ] The present invention relates generally to executing computer software programs generated by different com- 
pilers, and in particular to a method for enabling a first computer software program using a first binary specification to 
employ functionality of a second computer software program using a second binary specification. 

10 

Description of Related Art 

[0002] Many computer software programs, which are created in different programming languages, have to commu- 
nicate with each other. For example, a first computer software program, sometimes called the first software program, 

*5 created in a first computer programming language is able to provide tables. The first software program calls a second 
software program created in a second programming language, which is able to calculate figures that are needed in 
the table to be produced by the first software program. (As those of skill in the art will appreciate, when it is stated that 
a software program performs an action, this means that upon execution of the software program on a processor, the 
system including the processor performs the action in response to execution of an instruction or instructions in the 

20 software program.) 

[0003] Since the two software programs are written in different languages, the two software programs have different 
binary specifications. The second software program cannot be successfully called by the first software program because 
the different binary specifications prevents the second software program from correctly executing the call from the first 
software program. 

25 [0004] In this example, the different binary specifications result from different computer programming languages. 
However, binary specifications for the same computer programming language can be different based upon the differ- 
ences in the compilers for the same programming language. 

[0005] The prior art solution to this problem was to provide transformer modules for each required transformation 
route, for example from a certain first binary specification to a certain second binary specification. Since in modern 

30 computer applications, a certain software program may call many different software programs, the computer system 
requires a voluminous library of transformer modules. This extensive library needs significant storagespace and regular 
maintenance, since for every new binary specification, which shall be accessible, a full new set of transformer modules 
must be provided to each of the other binary specifications, in addition to the existing transformer modules. However, 
most of these transformer modules are not used frequently, so that their storage is not efficient. 

35 [0006] Furthermore, these prior art transformer modules extend to the full functionality of the software program to 
be translated from one binary specification to another. 

Due to the regularly wide functionality of software programs, known transformer modules are rather voluminous and 
require, when they are activated, a significant amount of working memory and processortime from the computer system 
on which they are executed. Furthermore, the complete translation of a software program is burdensome and time 
40 consuming, although it is in most cases unnecessary for the specific task to be accomplished. 

SUMMARY OF THE INVENTION 

[0007] Therefore, it is an object of the present invention to provide an efficient method to enable a first software 
45 program to employ certain functionalities of a second software program, wherein the first and the second software 
program use different binary specifications. 

[0008] The object of the invention is solved by the features of the independent claims. 

[0009] According to one embodiment of the present invention, an efficient method is provided to enable a first software 
program to employ certain functionalities of a second software program, where the first and the second software pro- 
50 gram use different binary specifications, i.e., the first and second software programs are in different execution envi- 
ronments. 

[0010] In one embodiment, a method for enabling a first software program using a first binary specification in a first 
execution environment to employ a limited functionality of a second software program using a second binary specifi- 
cation in a second execution environment first creates a bridge in the first execution environment. Using the bridge, a 
55 proxy wrapping an interface to the limited functionality of the second software program in the second execution envi- 
ronment is created in the first execution environment. 

[0011] In another embodiment, a method, dynamically implemented by a process in a first execution environment 
generates a binary specification object for the first execution environment. A binary specification object for a second 
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execution environment is also generated. Next the process generates a bridge object for mapping objects from the 
second execution environment to the first execution environment. For example, using the bridge object, the process 
generates a proxy wrapping an interface in the second execution environment. The interface in the second execution 
environment is used to access limited functionality in the second execution environment. 

5 [0012] In one embodiment, to use the limited functionality in the second execution environment in a first execution 
environment, a process executing in the first execution environment calls a method in a proxy interface in the first 
execution environment. In response to the call, the proxy interface converts the method to a corresponding method 
call for execution in the second execution environment. A method type description is used to convert parameters from 
the first execution environment to the second execution environment, and in one embodiment, a parameter type de- 

10 scription for the method is used. 

[001 3] The proxy interface dispatches the corresponding method call for execution in the second execution environ- 
ment to the second execution environment by the proxy interface. In response to the corresponding method call in the 
second execution environment, the method providing the limited functionality is executed and the results of the exe- 
cution are returned to the proxy interface. Using a type description, the returned results from the second execution 

*5 environment are converted to the first execution environment and returned to the calling process. In one embodiment, 
the second execution environment is a C++ programming language execution environment. 

[0014] In another embodiment of this invention, a computer program product comprises computer program code for 
a method for enabling a first software program using a first binary specification in a first execution environment to 
employ a limited functionality of a second software program using a second binary specification in a second execution 
2Q environment, the method comprising: 

creating a bridge in said first execution environment; and 

creating, in said first execution environment using said bridge, a proxy wrapping an interface to said limited func- 
tionality of said second software program in said second execution environment. 

25 

[0015] In another embodiment, a computer program product comprises computer program code for a method for 
using functionality in a second execution environment in a first execution environment, the method comprising: 

calling a method in a proxy interface in said first execution environment; and 

30 

converting said method call by said proxy interface to a corresponding method call for execution in said second 
execution environment. 



[001 6] One embodiment of the present invention includes a computer storage medium having stored therein a struc- 
35 ture comprising a binary specification for an execution environment that in turn includes a simple common identity 
structure. Optionally, the binary specification also includes an extended environment structure. In one embodiment, 
the simple common identity structure includes: a type name, a context, a pointer to the extended environment structure, 
and methods acquire, release and dispose. 

[0017] In a further embodiment, a method is provided for enabling a first software program using a first binary spec- 
40 ification to employ a limited functionality of a second software program using a second binary specification, including 
the following steps: 

a) initiating the creation of a stub, which is able to transform commands relating to the limited functionality of the 
second program between the second binary specification and an intermediate binary specification, using a second 

45 bridge, wherein the second bridge provides a mapping of the second binary specification and the intermediate 

binary specification, 

b) initiating the creation of a proxy, which is able to transform commands relating to the limited functionality of the 
second program between the first binary specification and the intermediate binary specification, using a first bridge, 

50 wherein the first bridge provides a mapping of the first binary specification and the intermediate binary specification, 

and 



c) initiating the arrangement of the proxy and the stub relatively to the first program and the second program in a 
manner allowing the first program to employ the limited functionality of the second program. 

[001 8] According to the present invention software programs are compiled executable programs. Software programs 
are initially written in a programming language, for example, C++ or Java or an object model like Corba. They are 
compiled with compilers corresponding to the programming language. However, for each programming language sev- 



3 



EP1 122 644 A1 



eral compilers may be available. The binary specification in which a software program is able to communicate with 
other software programs depends on both, the programming language and the compiler. This communication language 
of a software program is the language referred herein as the binary specification used by a software program, for 
example, the first, the second and the intermediate binary specification. 

5 [001 9] The intermediate binary specification serves as the binary specification into and from which the commun ication 
between the first and the second software program will be translated. This intermediate binary specification may be, 
for example, an existing binary specification like the binary specification of a specific compiler but it is also possible 
that this intermediate binary specification is a suitable newly created binary specification, for example, a binary spec- 
ification which facilitates translation into and from it. 

10 [0020] In the scope of the present invention the two transformer modules, called proxy and stub, are created on 
demand, that means if and when they are needed. This creation on demand will be initiated directly that means by the 
first software program or by means of an initiating function. This creation on demand is considered to be dynamic, so 
that the commands of the first software program may be dispatched dynamically. The two transformer modules are at 
least able to transform commands corresponding to a limited functionality of the second software program. Since the 

15 first software program employs in most cases only a part of the functionality of the second software program, the two 
transformer modules need to transform only commands which correspond to this limited functionality. In the scope of 
the present invention commands are understood to be any kind of message initiating any kind of activity of a software 
program and which may be transmitted between the two software programs. 

[0021] In the scope of the present invention it is possible to insert further modules between these two transformer 
20 modules. These modules may be able to intercept the commands. This interception may be used, for example, to add 
security or accounting functionality. It is also possible to use these two transformer modules to synchronize the com- 
mands or to use them for debugging. 

[0022] For the creation of the proxy and the stub mappings between the basic commands, on which all other com- 
mands are based, of the two pairs of participating binary specifications are used. These pairs are the first binary spee- 
ds ification and the intermediate binary specification and the second binary specification and the intermediate binary 
specification. These mappings will be provided by the bridges and may be, for example, stored in a database. However, 
the bridges may also already be a part of the second software program. In case these mappings cover the complete 
functionality of the relevant binary specifications - which is frequently the case - only some parts of the mapping may 
be considered during the creation of theproxy andthestub, since they relateto the above mentioned limited functionality 
30 only. 

[0023] After their creation the proxy and the stub are arranged in a manner which enables the first software program 
to communicate with the second software program. That means a path of communication must be arranged from the 
first software program to the proxy, from the proxy to the stub, and finally from the stub to the second software program. 
This route must regularly be accessible from both sides, that means from the side of the first software program as well 

55 as from the side of the second software program. 

[0024] In order to generate the stub the second binary specification used by the second software program must be 
known. For this purpose, the first software program may start the second software program. This may be done by the 
first program by means of a loader function which loads the second software program. Loader functions are well known 
in the prior art. A loader function is able to initiate a software program using a certain binary specification on demand 

40 of another software program using a different binary specification. The loader function may directly initiate the creation 
of the required stub or it may initiate that the second software program or an auxiliary program communicating with 
the second software program creates the stub. This is possible, if the loader function carries or supplies by any means 
the information about the limited functionality of the second software program requested by the first software program. 
[0025] The creation of the stub may be carried out by the second software program or by any sub-program of the 

45 second software program. It is possible that this sub-program exists already in the second software program. However, 
this sub-program may as well be procured or generated by the second software program in response to a request of 
the first software. 

[0026] After the creation of the stub, the initiated second software program or its sub-program creating the stub may 
inform the first software program that the stub has been created. This may initiate the creation of the proxy by the first 

50 software program or any suitable sub-program, as it was described above for the creation of the stub. 

[0027] The proxy is created by the first software program or a sub-program, a function thereof. The sub-program of 
the first software program must consider the bridge for the transformation of the first binary specification into the inter- 
mediate binary specification and reverse and the requested limited functionality of the second software program. The 
information about the requested limited functionality is generally available in the first software program, because the 

55 first software program requests this limited functionality from the second software program. 

[0028] In order to enable the communication between the first software program and the second software program 
the stub and the proxy may transform any commands or other messages between these two software programs, as 
far as the proxy and the stub support this functionality. This requires the above described arrangement of the proxy 
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and the stub relatively to the first and the second software program. 

[0029] The present invention also provides a method for employing a limited functionality of a second software pro- 
gram using a second binary specification by a first software program using a first binary specification . including the 
following steps: 

5 

a) initializing the limited functionality of the second software program by the first software program, 

b) creating a stub, which is able to transform commands relating to the limited functionality of the second software 
program between the second binary specification and an intermediate binary specification , using a second bridge, 

10 wherein the second bridge provides a mapping of the second binary specification and the intermediate binary 

specification, 

c) creating a proxy, which is able to transform commands relating to the limited functionality of the second software 
program between the first binary specification and the intermediate binary specification, using a first bridge, wherein 

*5 the first bridge provides a mapping of the first binary specification and the intermediate binary specification, 

d) transmitting an command relating to the limited functionality from the first software program to the proxy, 

e) transforming the command from the first binary specification into the intermediate binary specification by the 
20 proxy, 

f) transmitting the command transformed by the proxy from the proxy to the stub, 

g) transforming the transmitted command from the intermediate binary specification into the second binary spee- 
ds ification by the stub, 

h) transmitting the command transformed by the stub from the stub to the second software program, 

i) carrying out the command in the second software program and generating a response for the first software 
30 program, 

j) transmitting the response, being in the second binary specification, from the second software program to the stub, 

k) transforming the response from the second binary specification into the intermediate binary specification by the 
35 stub, 

I) transmitting the response transformed by the stub from the stub to the proxy, 

m) transforming the response from the intermediate binary specification into the first binary specification by the 
40 proxy, 

n) transmitting the response transformed by the proxy from the proxy to the first software program. 

[0030] The transmissions between the proxy and the stub and the software programs and the proxy or the stub, 
45 respectively may be effected by any suitable means. It is relevant, however, that these elements are arranged so as 
to allow the communication of the two software programs. 

[0031 ] Furthermore, a method for using a stub, which is able to transform commands relating to a limited functionality 
of a second software program between a second binary specification and an intermediate binary specification, using 
a second bridge, wherein the second bridge provides a mapping of the second binary specification and the intermediate 

50 binary specification, is provided for enabling a first software program using a first binary specification to employ the 
limited functionality of the second software program by further using a proxy, which is able to transform commands 
relating to the limited functionality of the second software program between the first binary specification and the inter- 
mediate binary specification, using a first bridge, wherein the first bridge provides a mapping of the first binary speci- 
fication and the intermediate binary specification, wherein the proxy and the stub are arranged relatively to the first 

55 software program and the second software program in a manner allowing the first software program to employ the 
limited functionality of the second software program. 

[0032] Also provided is a method for using a proxy, which is able to transform commands relating to the limited 
functionality of the second software program between the first binary specification and the intermediate binary speci- 
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fication, using a first bridge, wherein the first bridge provides a mapping of the first binary specification and the inter- 
mediate binary specification, for enabling a first software program using a first binary specification to employ the limited 
functionality of the second software program by further using a stub, which is able to transform commands relating to 
a limited functionality of a second software program between a second binary specification and an intermediate binary 
specification, using a second bridge, wherein the second bridge provides a mapping of the second binary specification 
and the intermediate binary specification, wherein the proxy and the stub are arranged relatively to the first software 
program and the second software program in a manner allowing the first software program to employ the limited func- 
tionality of the second software program. 

[0033] In the scope of the present invention there is also provided a computer program, also referred to as a computer 
program product, forcarrying out the method of the present invention . A computer program product comprises a medium 
configured to store or transport computer readable code, or in which computer readable code may be embedded. Some 
examples of computer program product are: CD-ROM disks, ROM-cards, floppy disks, magnetic tapes, computer hard 
drives, servers on a network and carrier waves and digital signals transmitted over a telecommunication link or network 
connection. 

[0034] Such computer program may be stored on any data carrier, such as, for example, a disk, a CD or a hard disk 
of a computer system. It is further provided a method for using a computer system, including standard computer sys- 
tems, for carrying out the present inventive method. Finally, the present invention relates to a computer system com- 
prising a storage medium on which a computer program for carrying out a method according to the present invention 
may be stored. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0035] 

Fig. 1 A is a high level representation of a first embodiment of the present invention; 

Fig. 1 B is a high level representation of a second embodiment of the present invention; 

Fig. 1 C is a more detailed representation of the first embodiment of the present invention; 

Figs. 2A and 2B are one embodiment of a binary representation of an environment according to one embodi- 

ment of the present invention; 

Figs. 3A and 3B are one embodiment of the binary specification structure of Fig. 2B; 

Fig. 4 is a sequence diagram illustrating one embodiment of making a proxy interface of the present 

invention, and one embodiment of using the proxy interface of the present invention; 

Fig. 5 is an example of a binary specification of the type representation in the UNO typelibrary ac- 

cording to one embodiment of the present invention; 

Fig. 6 is an illustration of stack configuration used in one embodiment of a C++ environment; 

Fig. 7A is an illustration of a virtual table in one embodiment of the present invention; 

Fig. 73 is an illustration of assembler code used to generate an index to a slot in the virtual table of 

Fig. 6; 

Fig. 8 is a process flow diagram for one embodiment of a method performed by a C++ proxy wrapping 

a UNO interface; 

Fig. 9 is a process flow diagram for one embodiment of a method mediate that is used by the method 

of Fig. 8; 

Fig. 10 is a process flow diagram for one embodiment of a method Env1_to_Env2 with interface that 

is used by method mediate of Fig. 9; 

Fig. 1 1 is a process flow diagram for one embodiment of a method performed by a U NO proxy wrapping 
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a C++ interface; 

Fig. 12 is a process flow diagram for one embodiment of a method Env2_to_Env1 with interface that 

used by the method of Fig. 1 1 ; 

Figs. 13A and 13B are an example of mapping an interface from a UNO environment to a C++ UNO environment 
according to one embodiment of the present invention; 

Fig. 14 is an example of freeing a C++ UNO interface proxy and revoking the proxy of the appropriate 

10 environment according to one embodiment of the present invention; 

Fig. 15 is an example of a C++ implementation of a C++ UNO proxy according to one embodiment of 

the present invention; 

15 Figs. 1 6A and 1 6B are an example of a C implementation of freeing a UNO interface proxy and functions acquire/ 

release according to one embodiment of the present invention; 

Figs. 17A and 17B are an example of mapping an interface from a C++ UNO environment to a UNO environment 
according to one embodiment of the present invention; 

20 

Fig. 18 is an example of a C++ implementation of a UNO proxy according to one embodiment of the 

present invention; 

Fig. 19 is an example of various constructors of a mapping and a bridge and of a free function of a 

25 bridge according to one embodiment of the present invention; 

Fig. 20 is an example of an implementation of functions acquire and release for a bridge according to 

one embodiment of the present invention; 

30 Fig. 21 is an example of an implementation to create a mapping between to environments according 

to one embodiment of the present invention: 

Figs. 22A and 22B are an example of an implementation to create the static part of an object identifier according 
to one embodiment of the present invention: 

35 

Fig. 23 is an example of an implementation to create an object identifier according to one embodiment 

of the present invention; 

Fig. 24 is an example of an implementation of methods acquire/release in a C++ UNO environment 

40 according to one embodiment of the present invention; 

Fig. 25 schematic representation of the inventive method in overview; 

Fig. 26 shows a flow chart: initial communication of a first and a second software program; 

45 

Fig. 27 shows a flow chart: creation of a stub; 

Fig. 28 shows a flow chart: creation of a proxy; 

50 Fig. 29 shows a flow chart: arranging a stub and a proxy; 

Fig. 30 shows a schematic representation of a computer system to be used in the scope of the present 

invention; 

55 Fig. 31 shows a representation of a client-server system to be used in the scope of the present inven- 

tion; 

Fig. 32 shows a flow chart: calling of a stub; 
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Fig. 33 



flow chart: calling of the second program through the stub; 



Fig. 34 



flow chart: binding a stub and a proxy; 



5 



Fig. 35 



shows a flow chart: calling the second software program from a first software program via a 
proxy and a stub; 



Fig. 36 



shows a flow chart: transforming and transmitting a command from the first software program 
to the second software program; 
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Fig. 37 



schematic representation of an interceptor arranged between a stub and a proxy; and 



Fig. 38 



shows a flow chart: use of an interceptor function in an arrangement of stub and proxy. 



15 [0036] In the Figures andthefollowing Detailed Description, elements with the same reference numeral are the same 
element or a similar element. Also, the first digit of a reference numeral for an element indicates the figure in which 
that element first appeared. 

DETAILED DESCRIPTION 



[0037] According to one embodiment of the present invention, a computing system 100 includes a service 111 , which 
is part of a first computer software program 1 1 0 executing within a first execution environment 1 20. Service 1 1 1 issues 
a call 1 1 2 to a service 1 61 of asecond computer software program 1 60 executing within a second execution environment 
1 50 that is different from first execution environment 1 20. For example, service 1 1 1 , in one embodiment, is a part of a 
25 word processing program that issues a call to a calculator, which is service 161, of a spreadsheet program, where the 
word processing program is written in a Visual Basic computer programming language, and the calculator is written in 
the C programming language. 

[0038] Unlike the prior art in which calls to a different execution environment with a different binary specification 
could not be handled in most cases, and in a limited number of cases could be handled by marshalling the call into a 

30 specific predefined byte stream (for example the CORBA byte stream) for passing to the different execution environ- 
ment, call 112 from first execution environment 120 with a first binary specification is directed to a proxy 130 in a bridge 
1 40. Proxy 1 30 converts any parameters in the call to parameters for second execution environment 1 50 using a type 
description that is described more completely below, and then dispatches a call 170, with the converted parameters, 
to service 1 61 in second execution environment 1 50. Call 1 70 corresponds to call 1 1 2 in first execution environment 1 20. 

35 [0039] In response to call 170 from proxy 130, service 161 performs the action requested and returns the result to 
proxy 130. Proxy 130 converts the result and any parameters returned from second execution environment 150 to first 
execution environment 120. The converted results are in turn provided to service 111 . 

[0040] Hence, according to one embodiment of the present invention, a first service, sometimes called a component 
or an object, with a first binary specification in a first execution environment utilizes a second service sometimes called 

40 a component or an object, in a second execution environment with a second binary specification that is different from 
the first binary specification. This greatly extends and facilitates providing an application with a broad range of capa- 
bilities without having to port the application and/or all of the capabilities to the binary specification of each execution 
environment in which the application may run. In addition, this embodiment facilitates providing a particularfunctionality 
to an application that is executed in an execution environmentthat does not, and perhaps cannot, support that particular 

45 functionality. 

[0041] In the embodiment of Figure 1A, proxy 130 is instantiated by bridge 140 that is in first execution environment 
120 and proxy 130 communicates directly with service 161 that is in second execution environment 150. However, in 
another embodiment, proxy 130A in response to a call 112 from service 111 of software program 110 issues a call 131 
to an intermediary proxy 185 in execution environment 180 that is different from both execution environment 120 and 

50 execution environment 150, in this example. 

[0042] Intermediary proxy 130A converts the call from the first binary specification to the binary specification for 
execution environment 180 and dispatches a call 131 to intermediary proxy 185. Intermediary proxy 185 converts the 
call from the binary specification of execution environment 180 to the binary specification of execution environment 
1 50 and then dispatches call 1 86 to service 1 61 . The response from service 1 61 is returned to intermediary proxy 1 85 

55 that converts the response to binary specification of execution environment 1 80, and in turn transmits the converted 
response to proxy 130A. Proxy 130A converts the response from the binary specification for execution environment 
1 80 to the binary specification for execution environment 1 20 and returns the result to service 1 1 1 of software program 
110. 



20 
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[0043] To reduce the number of bridges, normally only bridges to intermediate environment 180, referred to herein 
as the binary UNO specification environment, exist. To make a bridge from a C programming language (C) execution 
environment to a C++ programming language (C++) execution environment, call traffic is delegated over two bridges 
140A and 190. First bridge 140A is from the C execution environment to the binary UNO execution environment and 
5 then bridge 1 90 is from the binary UNO execution environment to the C++ execution environment. In this way, only (n 
-1) bridges are needed for n different environments instead of n*(n - 1)/2 bridges, if a direct connection between envi- 
ronments is made as in Fig. 1 A. Preferably each bridge can create proxy objects only from the description of an interface. 
This implies that the code may be generated at runtime. 

[0044] Returning to Figure 1 A, as explained more completely below, a source environment object 103 and a desti- 
ne nation environment object 104 are initially created using a runtime library, and optionally registered in an execution 
environment, e.g., execution environment 120. Each of objects 103 and 104 includes a binary specification structure 
for its respective execution environment. As explained more completely below, a binary specification structure, in one 
embodiment, provides common functions for each environment, and knows all proxies, sometimes called proxy inter- 
faces, and their origins. Thus, an execution environment, through its binary specification structure, knows each wrapped 
*5 interface, i.e., proxy, running in execution environment and the origin of each of these wrapped interfaces. 

[0045] After the objects 1 03 and 1 04 are created, a call is made by service 1 1 1 that results in a search for a shared 
library that is activated as a bridge for the two execution environments. Each bridge, e.g., bridge 140, is implemented 
in a separate shared library. In one embodiment, the name of the shared library is a connection of two environment 
names with an underscore ('_') between the names. 
20 [0046] Next a call is made by service 1 1 1 to map an interface of the source environment. Mapping is the direct way 
to publish an interface in another environment. That means an interface is mapped from a source environment 1 50 to 
a destination environment 120 so that methods may be invoked on a mapped interface, i.e., proxy 130, in destination 
environment 120, which, in turn, are delegated to the originating interface in the source environment. 
[0047] Mapping an interface from an environment 150 to an environment 120 requires several operations that are 
25 described more completely below with respect to Figure 4. However, briefly, a call is made to bridge 140 to map a 
particular interface for service 161 in source execution environment 150 to destination execution environment 120. If 
a proxy already exists for this mapping, a handle to the proxy is returned to service 111. Alternatively, as explained 
below, bridge 1 40 creates proxy 1 30, and returns a handle to service 1 1 1 so that subsequent calls to the interface for 
service 161 are directed to proxy 130. 
30 [0048] Hence, as used herein, abridge 140 in a first environment 120 is defined to be a software module that upon 
execution initially creates a proxy object 130 in first environment 120 for one computer programming language and 
hardware platform so that an actual object 1 61 , sometimes called real object 161, represented by proxy 1 30, is available 
from a second environment 150. Proxy object 130 looks like and is an object implemented in first environment 120, 
and so proxy object 130 can be transparently used. Proxy object 130 delegates calls to real object 161 in second 
55 environment 150. 

[0049] In one embodiment, real object 161 in second environment 150 is implemented in the C programming lan- 
guage (C) and real object 161 is accessed from a C++ programming language (C++) environment. In this case, bridge 
140 is from a C++ environment to a C environment. Remember that C++ is incompatible between different compilers 
and different switches. Bridge 140 creates a C++ proxy object 130 in first environment 120, which delegates calls to 
40 real object 161 implemented in C. Sometimes a bridge is called language binding, but this description is not exact, 
because bridges also connect object models in another embodiment of the present invention. 

[0050] The particular configuration of computing system 1 00 is not essential to this invention. Execution environments 
120 and 150, in one embodiment, are included within the same computer. 

[0051] In another embodiment, execution environment 120 is in a client system and execution environment 150 is 
45 in a server system. In this embodiment, the client system can be a mobile telephone, a two-way pager, a portable 
computer, a workstation, or perhaps a personal computer. The client and server can be interconnected by a local area 
network, a wide area network, or the Internet. As explained more completely below, the dynamic dispatch functionality 
of this invention is independent of the network protocol and the network architecture. In yet another embodiment, 
execution environment 120 is in a first computer and execution environment 150 is in a second computer where the 
50 first and second computers are in a peer-to-peer network. 

[0052] Figure 1 C is an example of a user device 1 02 that is executing service 1 1 1 of application 1 1 0 from a volatile 
memory 1 22 on CPU 1 01 . Application 1 1 0 can be any application, or an application in a suite of applications that can 
include for example a word processing application, a spreadsheet application, a database application, a graphics and 
drawing application, an e-mail application, a contacts manager application, a schedule application, and a presentation 
55 application. One office application package suitable for use with this embodiment of the invention, is the STAROFFICE 
Application Suite available from Sun Microsystems, 901 San Antonio Road, Palo Alto, CA. (STAROFFICE is a trade- 
mark of Sun Microsystems, Inc.) 

The user has access to the functionality of service 1 61 even thought the execution environment for computer 1 55 is 
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different from the execution environment of user device 1 02 and even in situations where in addition user device 1 02 
has neither the memory capacity nor the processing power to execute service 1 61 . 

[0053] In the embodiment of Figure 1C, a runtime library 108 is initially stored in a non-volatile memory 121 and a 
part or all of runtime library 1 08 is moved to volatile memory 1 22 to generate source environment object 1 03, destination 
5 environment object 104 and bridge 140. In one embodiment, bridge 140 includes a shared library and is the same 
library as runtime library 108. 

[0054] In this embodiment, when proxy 130 receives a method call from service 111 , proxy 130 dispatches the call 
to service 1 61 via I/O interface 1 22 that is connected to network interface 1 83 of computer 1 55 via networks 1 05 and 1 06 . 
[0055] Those skilled in the art will readily understand that the operations and actions described herein represent 

10 actions performed by a CPU of a computer in accordance with computer instructions provided by a computer program. 
Therefore, bridge 140, proxy 130, source environment object 103, and destination environment object 104 may be 
implemented by a computer program causing the CPU of the computer to carry out instructions representing the indi- 
vidual operations or actions as described herein. The computer instructions can also be stored on a computer-readable 
medium, or they can be embodied in any computer-readable medium such as any communications link, like a trans- 

15 mission link to a LAN, a link to the internet, or the like. 

[0056] Thus, all or part of the present invention can be implemented by a computer program comprising computer 
program code or application code. This application code or computer program code may be embodied in any form of 
a computer program product. A computer program product comprises a medium configured to store or transport this 
computer-readable code, or in which this computer-readable code may be embedded. Some examples of computer 

20 program products are CD-ROM discs, ROM cards, floppy discs, magnetic tapes, computer hard drives, servers on a 
network, and carrier waves. The computer program product may also comprise signals, which do not use carrier waves, 
such as digital signals transmitted over a network (including the Internet) without the use of a carrier wave. 
[0057] The storage medium including runtime library 1 08 may belong to user device 1 02 itself. However, the storage 
medium also may be removed from user device 102. The only requirement is that the runtime library is accessible by 

25 user device 1 02 so that the computer code corresponding to the environment objects, bridge and proxy can be executed 
by user device 1 02. Moreover, runtime library 1 08 can be downloaded from another computer coupled to user device 
1 02 via a network. Also, user device 1 02, as explained above, can also be a server computer and so the configuration 
of Figure 1 C is illustrative only and is not intended to limit the invention to the specific embodiment shown. 
[0058] Herein, a computer memory refers to a volatile memory, a non-volatile memory, or a combination of the two 

30 in any one of these devices. Similarly, a computer input unit and a display unit referto thefeatures providing the required 
functionality to input the information described herein, and to display the information described herein, respectively, in 
any one of the aforementioned or equivalent devices. 

[0059] As used herein , software programs are compiled executable programs. Software programs are initially written 
in a programming language, for example, C, C++ or JAVA or an object model like CORBA or UNO. They are compiled 

55 with compilers corresponding to the programming language. However, for each programming language several com- 
pilers maybe available. The binary specification in which a software program is able to communicate with other software 
programs depends on both, the programming language and the compiler. This communication language of a software 
program is the language referred herein as the binary specification used by a software program. 
[0060] As used herein, an execution environment, such as execution environments 120 and 150, contains all objects, 

40 which have the same binary specification and which lie in the same process address space. The execution environment, 
sometimes called environment, herein, is specific for a computer programming language and for a compiler for that 
computer programming language. For example, an object resides in the "msci" execution environment, if the object is 
implemented with a software program written in the C++ computer programming language, and the software program 
is compiled with the MICROSOFT Visual C++ compiler. (MICROSOFT is a trademark of Microsoft Corp. of Redmond, 

45 WA) An example of a binary specification for one sample execution environment is presented below in conjunction 
with the description of Table 1 . 

[0061] To assist in the understanding of this invention, examples of a binary specification for an environment, and 
types, type libraries, and a type repository are first considered, and then embodiments to make and use the present 
invention are described. 

50 

Binary Specification for an Execution Environment. 

[0062] The function of a binary specification for an execution environment is to identify the execution environment, 
and optionally to provide functionality like interface registration. In one embodiment, the structure of a binary specifi- 
cs cation for an execution environment is split into a simple common identity structure 220 (See Fig. 2A) that is easily 
implemented for bridges that handle object identity issues. An optional structure 225 may be included to support optional 
functionality. In one embodiment, the optional functionality includes interface registration, acquiring/releasing in inter- 
faces of the environment, and obtaining an object identifier for an interface. 



10 



EP 1 122 644 A1 



[0063] Table 1 is an example of a simple common identity structure 220 (Fig. 2) of a binary specificaiton for an 
execution environment called uno_enviroment. 



10 



TABLE 1.: One Embodiment of a Simple Common Identity 
Structure for a Binary Specification of an Execution 

Environment 



typedef struct _uno_Environment 
{ 

void * pReserved; 
rtl_uString * pTypeName; 
void * pContext; 
uno^ExtEnvironment * pExtEnv; 

void ( SAL__CALL * acquire) ( uno_Environment * pEnv ) ; 
void (SAL_CALL * release) ( uno_Environment * pEnv ); 
void (SAL_CALL * dispose) ( uno^Environment * pEnv ); 
void (SAL__CALL * envi ronment Dispos ing ) ( 
uno__Environment * pEnv ) ; 
} uno Environment; 



35 



[0064] Pointer pReserved in the UNO environment is reserved and so in this embodiment is set to zero. String 
pTypeName is a type name of the environment. Pointer pContext is a free context pointer that is used for specific 
40 classes of environments, e.g., a JAVA virtual machine pointer. (JAVA is a trademark of Sun Microsystems, Inc. of Palo 
Alto, CA.) Pointer pExtEnv is a pointer to and extended environment (interface registration functionality), if supported, 
and otherwise is set to zero. 

[0065] Method acquire acquires this environment, i.e., the environment defined by this structure. Parameter pEnv is 
this environment. Method release releases this environment and again parameter pEnv is this environment. Method 
45 dispose is explicitly called to dispose of this environment, e.g., to release all interfaces. Typically, this method is called 
before shutting down to prevent a runtime error. 

[0066] In this embodiment, method disposing is a disposing callback function pointer that can be set to be signaled 
before this environment is destroyed. This method is late initialized by a matching bridge and is not for public use 
[0067] Hence, in the embodiment, each simple common identity binary specification structure for an environment 
50 includes a type name of the environment; a free context pointer, a pointer to an extended environment that includes 
optional functionality, and methods to acquire, release and dispose of the environment. Structure 220 is stored in a 
memory 21 0 of computer system 1 00. 



55 
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TABLE 2.: One Embodiment of an Extended Environment 
Structure for a Binary Specification of an Execution 

Environment 



typedef struct _uno_ExtEnvironment 



urio Environment aBase; 

void (SAL_CALL * registerlnterf ace) ( 

uno_ExtEnvironment * pEnv, 

void pplnterface, 

rtl_uString * pOId, 

typelib_InterfaceTypeDescription * pTypeDescr ) / 
void (SAL_CALL * registerProxylnt erf ace ) ( 
uno_Ext Environment * pEnv, 
void ** ppProxy, 
uno_f reeProxyFunc f ree Proxy , 
rtl_uStnng * pOId, 

typelib_InterfaceTypeDescript ion * pTypeDescr ) ; 
void (SAL_CALL * revokelnterf ace ) ( 

uno_ExtEnvironment * pEnv, void * plnterface ) ; 
void (SAL_CALL * getOb j ect Identifier ) ( 

uno__ExtEnvironment * pEnv, 

rtl_uStrmg ppOId, 

void * plnterface ) ; 
void ( SAL__CALL * getRegisteredlnter f ace ) ( 

uno_ExtEnvironment * pEnv, 

void pplnterface, 

rtl_uString * pOId, 

typelib_Interf aceTypeDescription * pTypeDescr ) ; 
void (SALJ3ALL * getRegis teredlnterf aces ) ( 
uno_ExtEnvironment * pEnv, 
void *** ppplnterf aces, 
sal_Int32 * pnLen, 
uno memAlloc memAlloc ) ; 



55 
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void (SAL__CALL * computeObj ect Identifier ) ( 
uno_ExtEnvironment * pEnv, 

rtl_uString ** ppOId, void * plnterface ) ; 
void (SAL_CALL * acquirelnter f ace ) ( 

uno_ExtEnvironment * pEnv, void * plnterface ) ; 
void (SAL_CALL * release Inter face ) ( 

uno_ExtEnvironment * pEnv, void * plnterface ) ; 
} uno ExtEnvironment; 



[0068] Table 2 is one embodiment of a binary specification of an UNO environment supporting interface registration. 

20 This binary specification inherits all members of a uno_Environment as defined, for example, by Table 1 above. 

[0069] Method registerlnterface in Table 2 registers an interface of this environment. Parameter pEnv is this envi- 
ronment. Parameter pplnterface is an inout parameter of the interface to be registered. Parameter pOld is an object 
id of the interface to be registered, and parameter is a type description of interface to be registered. 
[0070] Method registerProxy Interface in Table 2 registers a proxy interface of this environment. The proxy interface 

25 can be reanimatedand isfreed explicitly by this environment. In this call, parameter pEnv is this environment. Parameter 
pplnterface is an inout parameter of interface to be registered. Parameter freeProxy represents a function to free this 
proxy object (See Table 3). Parameter pOld is an object id of the interface to be registered, and parameter is a type 
description of interface to be registered. 

[0071] Method revoke Interface revokes an interface from this environment. Any interface that has been registered 
30 must be revoked via this method. In the call to this method, parameter pEnv is this environment, and parameter pln- 
terface is the interface to be revoked. 

[0072] Method getObjectldentifier provides the object id of a given interface. In this method, parameter ppOId is the 
input and output object identifier (oid), and parameter plnterface is the interface of the object. 

[0073] Method getRegistered Interface retrieves an interface identified by its object id and type from this environment. 
55 Interfaces are retrieved in the same order as they are registered. In this method, parameter pEnv is this environment. 
Parameter pplnterface is the inout parameter for the registered interface and is zero if none was found. Parameter 
pOld is the object id of the interface to be retrieved, and parameter pTypeDescr is a type description of interface to be 
retrieved. 

[0074] Method getRegistered Interfaces return all currently registered interfaces of this environment. The memory 
40 block allocated might be slightly largerthan (*pnl_en *sizeof(void *)). Inthis method, parameterpEnv isthis environment. 
Parameter pplnterfaces is an output parameter that is a pointer to an array of interface pointers. Parameter pnLen is 
an output parameter to a length of the array of interface pointers, and parameter memAlloc represents a function for 
allocating memory that is passed back (See Table 4). 

[0075] Methods computeObjectldentifier, acquire Interface and releaselnterface are late initialized by a matching 
45 bridge and are not for public use. Method computeObjectldentifier computes an object id of the given interface, and is 
called by the environment implementation. ParameterpEnv isthis environment, Parameter ppO Id is an output param- 
eter that is the computed id. Parameter plnterface is the given interface. Methods acquire Interface and releaselnterface 
are methods to acquire an interface, and release an interface respectively. The input parameters are defined the same 
as in method computeObjectldentifier. 
50 [0076] Table 3 is one embodiment of a generic function pointer declaration to free a proxy object, if an environment 
does not need the proxy object anymore. To use this function, the proxy object must register itself on the first call to 
method acquire() (See Table 1 ) call and revoke itself on the last call to method release() (See Table 1 ). This can happen 
several times because the environment caches proxy objects until the environment explicitly frees the proxy object by 
calling this function. In the call to this method, parameter pEnv the environment, and parameter pProxy is the proxy 
55 pointer. 
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TABLE 3.: One Embodiment of a Definition for 
Function FreeProxyFunc 



typedef void (SAL_CALL * uno_f reeProxyFunc ) ( 

uno_Ext Environment * pEnv, void * pProxy ) ; 



15 

[0077] Method memAlloc (Table 4) is a generic function pointer declaration to allocate memory. This method is used 
with method getRegisteredlnterfaces() (Table 2). Parameter nBytes is the amount of memory in bytes. This method 
returns a pointer to the allocated memory. 



TABLE 4.: One Embodiment of a Definition for 
Function memAlloc 

25 



typedef void * (SAL_CALL * uno_memAlloc ) ( sal_ulnt32 
nBytes ) ; 



35 

[0078] An alternative embodiment of a structure 230 for a binary specification of an execution environment is pre- 
sented in Figure 2B. In this embodiment, all the information including methods needed to manage registering and 
unregistering interfaces are includes in a single structure. Figures 3A and 3B are the information in one embodiment 
of structure 230. Alternatively, the information in Tables 2 and 3 could be combined into a single structure. 

40 [0079] To use environments, the environments are registered. An existing environment is obtaining by calling a meth- 
od for getting the environment. For the example of Table 1 , method uno_getEnvironment() is used. A new environment 
is created by either implementing the new environment directly, or by using a simple default implementation, which is 
frequently also sufficient, by calling, in the given example, method uno createDefaultEnvironment() with the environ- 
ment's name and the environment's acquire and release functions for interfaces. 

45 [0080] Within execution environments, type descriptions are used to map types between environments. A type de- 
scription may exist or may be created at runtime. Each existing type in an execution environment is stored in a type 
repository along with the corresponding type description. The type descriptions are accessible through the full name 
of each type in the type repository, in one embodiment. For example, the full name of interface type "Xlnterface" may 
be "com.sun.star.XInterface". The naming conventions used to access a type and/or a type description within the type 

50 repository are not an essential feature of this invention, and any suitable naming convention can be utilized. In a type 
repository, the types and associated type descriptions are stored in any appropriate way. 

[0081] If the API (application program interface) of the type repository is a C programming language style, the type 
repository API is directly, that means via a binary representation, accessible from many binary specifications, and the 
type repository API is quickly transferable. Since the type description of each element may be used during the generic 
55 marshaling of a call, in one embodiment, C-style structures, which describe each type, are used. 

[0082] Figure 5 is an example of a binary specification 500 of the type representation in the UNO typelibrary. The 
type library includes complete type descriptions for each existing IDL type. These type descriptions are organized in 
a hierarchical form, which represents the IDL module structure including a node forthe type itself. Each type node has 
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a binary type blob, which contains the complete type information. The structure of the type blob depends on the kind 
of the type. The first part is relevant for each type and the other parts depend on the type. For example, a structure 
has only an additional field section because it isn't possible to specify methods for structures. 

[0083] In this embodiment, the structure includes a header section; a constant pool section; a field section; and a 
5 reference section. A definition of the information is each section, as illustrated in Figure 5 is given herein. 

Header section 
10 magic, type: sal_ulnt32 

a reserved field for internal use. 
size, type: sai_ulnt32 
15 represents the size of the blob in bytes. 

minor .major version, type: sal_ulntl6 

two fields to specify a version number for 
the binary format. 

20 

nHeaderFields, type: sal_ulntl6 

specifies the number of fields in the header 
section. This number is used for 
25 calculating the offset of the next 

section . 
typeSource, type: sal_ulntl6 
30 specifies in which language the type was 

defined, e.g. UNO IDL, CORBA 1DL or 
Java . 

typeClass , type: sal_ulnt!6 
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specify the typeclass of the described type, 
e.g. interface or enum, 
name, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool which specifies the 
full qualified name of the type. 
Uik, type: sal_ulntl6 

represents an index for a Uik item in the 
constant item pool which contains the 
Uik information for an interface. This 
field is 0 if the type is not an 
interface . 
docu, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool which contains the 
documentation of this type. 
filename, type sal__ulntl6 

represents an index for a string item in the 
constant item pool which specifies the 
name of the source file where the type 
is defined. 
nSuperTypes, type: sal_ulntl6 

specifies the count of supertypes. This field 
is only relevant for structs, 
exceptions, services and interfaces. If 
nSuperTypes > 0 than the next section is 
an area with size nSuperTypes * 
sal_ulntl6, which represents indices for 
string items in the constant pool. 

Constant pool section 

[0084] The constant pool section consists of nConstantPoolCount entries of variable length and type. Each entry 
constists of three fields: 
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10 



size, type: sal__ulnt32 

specifies the size of the entry in bytes 
type tag, type: sal__ulntl 6 

specifies the type of the data field. 
data, type: sal_ulnt8 

specifies the raw data of the entry with 
(size - sizeof (sal_ulnt32) - 
sizeof (sal_ulntl6) ) bytes. 

15 

Field section 

[0085] The field section represents type information for struct or exception members, const types, enums, service 
20 members and attributes of interfaces. This section only exists if the field nFieldCount is greater than zero. 



25 



30 



nFieldCount , type: sal_ulnt!6 

specifies the number of fields in the field 
section . 

nFieldEntries, type: sal_ulntl6 

specifies the number of fields for each entry 
in the field section. This number is 
used for calculating the offsets in the 
35 field section. 

access, type: sal_ulntl6 

specifies the access of the field, e.g. 
readonly . 
name, type: sal_ulntl 6 

represents an index for a string item in the 
constant item pool, which specifies the 
name of the field. 
typename, type: sal_ulntl6 

50 



40 



45 



55 
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represents an index for a string item in the 
constant item pool, which specifies the 

5 

full-qualified typename of the field. 
value, type: sal_ulntl6 

represents an index for an item in the 
10 constant item pool with the same type 

specified by typename which represents 
the value of the field, e.g., the 
15 initial enum value or the value of a 

constant. This field could be 0. 
docu, type: sal_ulntl6 
2Q represents an index for a string item in the 

constant item pool, which contains the 
documentation of this field. 
filename, type: sal_ulntl6 

25 

represents an index for a string item in the 
constant item pool, which specifies the 
name of the source file where the field 

30 is defined. This could be different 

from the filename in the header section, 
because constants could be defined in 

« different source files. 



Method section 

40 [0086] The method section represents type information for interface methods. This section only exists if the field 
nMethodCount is greater than zero. 



nMethodCount, type: sal_ulnt!6 

specifies the number of methods in the method 
section . 

nMethodEntries , type: sal_ulnt!6 
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specifies the number of fields for each entry 
in the method section. This number is 
used for calculating the offsets in the 
method section. 
nParameterEntries, type: sal_ulntl 6 

specifies the number of fields for each entry 
in a parameter section. This number is 
used for calculating the offsets in the 
parameter section. 
size, type: sal_ulntl6 

specifies the size of the current method 
entry in bytes. 
mode, type: sal_ulntl6 

specifies the mode of the method, e.g., 
oneway . 
name, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which specifies the 
30 name of the method. 

returntype, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which specifies the 
full-qualified typename of the 
returntype of the method. 
docu, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which contains the 
documentation of this method. 
nParamCount , type: sal_ulntl6 

specifies the number of parameters for this 
method. If parameters exist, the 
parameter section follows this field, 
type, type: sal_ulntl 6 

represents an index for a string item in the 
constant item pool, which specifies the 

55 
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10 



full-qualified typename of the 
parameter . 
mode, type: sal_ulntl6 

specifies the mode of the method, e.g., in, 
out or inout. 
name, type: sal_ulntl6 

represents an index for a string item in the 
15 constant item pool, which specifies the 

name of the parameter. 
nExceptionCount, type: sal_ulntl6 

specifies the number of exceptions for this 
method. If exceptions exist the 
exception section follows this field. 
excpName 1 . . . n, type: sal_ulntl6 

represent indices for string items in the 

constant item pool, which specifies the 
full-qualified name of exceptions. 

30 

Reference section 

[0087] The reference section represents type information for references in services. This section only exists if the 
35 field nReferenceCount is greater than zero. 



20 



25 



45 



nReferenceCount , type: sal_ulntl6 
^0 specifies the number of references for this 

type. 

nReferenceEntries, type: sal_ulntl 6 

specifies the number of fields for each entry 
in the reference section. This number 
is used for calculating the offsets in 
the reference section. 
typename, type: sal_ulntl6 

represents an index for a string item in the 
consLdnL ilem pool, which specifies the 

55 
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full-qualified typename of the 
5 reference. 

name, type: sal_ulntl6 

represents an index for a string item in the 
constant item pool, which specifies the 

10 

name of the reference. 
docu, type: sal_ulntl6 

represents an index for a string item in the 
15 constant item pool, which contains the 

documentation of this reference. 
access, type: sal__ulntl6 
20 specifies the access of the reference, e.g. 

needs, observes or interface. 



[0088] In one embodiment of a type repository, all functions or type declarations have a prefix "typelib_". In one 
25 embodiment of the type repository API , a function typelib_TypeDescription_newlnterface is used to create an interface 
description. The descriptions of structures, unions and sequences are created with a function typelib 
TypeDescription_new. The description of a base type is initially part of type repository. A function that gets a type 
description is function typelib TypeDescription_getByName in the type repository API. 

[0089] A JAVA API to a type repository is different for two reasons. First, the JAVA classes cannot access the binary 
30 representation of the type descriptions directly Second, the JAVA runtime system provides an API (core reflection) 
similar to the type repository API. Unfortunately, the features "unsigned", "oneway" and "out parameters" are missing 
in this API. For this reason, additional information is written into the JAVA classes to provide the functionality of these 
features. 

[0090] The representation of the types depends on the hardware, the language and the operating system. The base 
35 type is swapped, for example, if the processor has little or big endian format. The size of the types may vary depending 
on the processor bus size. The alignment is processor and bus dependent. The alignment of the data structure is 
defined as follows: 

Structure members are stored sequentially in the order in which the structure members are declared. 
Every data object has an alignment-requirement. 
40 For a structure, the alignment requirement is determined the largest object of the structure. 
Every object is allocated an offset so that offset 
% aiignment-requirement == 0. 

[0091] If it is possible that the maximum alignment can be restricted (MICROSOFT C/C++ compiler, IBM C/C++ 
compiler), the maximum alignment is set to eight. 
45 Under this condition, the alignment is set to min( n, sizeof( item ) ) where n is maximum alignment. The size is rounded 
up to the largest integral base type. For the MICROSOFT and IBM C/C++ compiler the alignment of a structure is set 
to eight using the "#pragma" statement. 

[0092] Table 5 shows the type and type definitions for one embodiment of the UNO, C++ and the JAVA execution 
environments. 

50 

Table 5. 





Environment 


Type 


UNO 


C++ 


JAVA 


Byte 


Signed 8 Bit 


Signed 8 Bit 


Signed 8 Bit 


Short 


Signed 16 Bit 


Signed 16 Bit 


Signed 16 Bit 
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Table 5. (continued) 







Environment 




Type 


UNO 


C++ 


JAVA 


5 


Ushort 


Unsigned 16 Bit 


Unsigned 16 Bit 


Signed 16 Bit 




Long 


Signed 32 Bit 


Signed 32 Bit 


Signed 32 Bit 




Ulong 


unsignea dii 


unsignea bit 


oignea dil 


10 


Hyper 


Signed 64 Bit 


Signed 64 Bit 


Signed 64 Bit 




U hyper 


Unsigned 64 Bit 


Unsigned 64 Bit 


Signed 64 Bit 




Float 


Processor dependent: Intel, 
Snarr — IFFF flnat 


Processor dependent: Intel, 
Q nar o _ IFFF flnat 

OjJCllO — 1 LLL IIUdL 


IEEE float 


15 


Double 


nuucooui uejjei luei il. iiilci, 

Sparc = IEEE double 


nuucooui ljc|jci luei i l . iiilci. 

Sparc = IEEE double 


IFFF rinuhlp 

II L 1_ UUUUIC 


20 


Enum 


Thp <^i7P nf a manhinp wnrH 

MIC o 1 Z_C \J\ d 1 1 1 aU 1 1 1 1 1 C VVUI U, 

Normally, this is the size of an 
integer. 


Thp <5i7P nf a manhinp wnrd 

i i ic oilc \j\ a ill au 1 1 1 1 i c vv u i u . 

Normally, this is the size of an 
integer. 


All pnnin valup^ nf nnp pnum 

i\ 1 1 CI IUM 1 ValU Co KJ 1 Ul IC CM Ul 1 1 

declaration are a static object of 
a class. Each object contains a 
32-bit value, which represents 
the enumeration value. 




Boolean 


1 Byte. 


1 Byte. 


Boolean 


25 


Char 


1 6 Bit on WNT, W95, W98, and 
Os2. 32 Bit on Unix 


1 6 Bit on WNT, W95, W98, and 
Os2. 32 Bit on Unix 


Unsigned 16 bit (char) 


30 


String 


pointer to a structure which 
have the following members: 
long refCount; long length; 
wchar_tbuffer[...]; The string in 
buffer is 0 terminated. This is 
the rtl_wString structure in the 
rtl-library 


pointer to a structure which 
have the following members: 
long refCount; long length; 
wchar_t buffer[...]; The string in 
buffer is 0 terminated. This is the 
rtl_wString structure in the rtl- 
library 


java.lang. String 


35 


Structure 


The structure contains the 
members in the order of the 
declaration. 


The structure contains the 
members in the order of the 
members declaration. 


A class, which is derived from 
java.lang. Object and contains 
the in the specified order. 


40 


Union 


The size is 4 + size of the 
largest type. In front of the 
union members is a long value 
(nSelect), which describes the 
position of the valid member (0 
is the first). 


Thesizeis4 + sizeof the largest 
type. In front of the union 
members is a long value 
(nSelect), which describe the 
position of the valid member (0 
is the first). 


Not specified 


45 
50 


Sequence 


A pointer to a structure which 
has the 

following members: void * 
pElements; long nElements; 
long nRefCount; The 
pElements are a memory area 
that contains nElements 
elements. 


A pointer to a structure which 
has the 

following members: void * 
pElements; long nElements; 
long nRefCount; The pElements 
are a memory area that contains 
nElements elements. 


A normal JAVA array. 


55 


Exception 


Looks like a structure 


Looks like a structure 


A class, which is derived from 
java.lang. Except ion and 
contains the members in the 
specified order. 
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Table 5. (continued) 





Environment 


Type 


UNO 


C++ 


JAVA 


Interface 


Is a pointer to a function table, 
which contains at least three 
functions. 


Is a pointer to a C++-Class 
which implements, implements 
first the virtual methods 
query Interface, acquire and 
release. 


A normal JAVA interface. 


Any 


A structure that contains a 
pointer to a type description. 
The second member is a 

pointer to the value stored in 
the any. 


A structure that contains a 
pointer to a type description. 
The second member is a 

pointerto the value stored in the 
any. 


A class which is derived from 
java.lang.Objec t". The 
members are a class, which 
describe the type of the 
value. A second member which 
is the value of the any. 


Void 


No memory representation 


No memory representation 


No memory representation 



20 [0093] Many of the types in TABLE 5 are self-explanatory and known in the art. Nevertheless, the most relevant 
types are explained in more detail below. 

Interfaces: 

25 [0094] All interfaces employed in connection with the present embodiment are derived from a super-interface class. 
Each interface contains at least three methods. Two methods "acquire" and "release" are necessary to control the 
lifetime of the interface. A third method "query Interface" is used to navigate between different interfaces. In the UNO 
environment, an interface Xlnterface includes only these three methods. All other interfaces in the UNO environment 
are derived from this interface Xlnterface. 

30 [0095] In a JAVA environment, for example, interfaces are mapped to JAVA interfaces, which could be normally 
implemented. Methods acquire and release are not mapped to the JAVA program, since these methods do not exist 
in the JAVA programming language The lifetimes of the proxy and the relevant information in a second JAVA program 
are controlled by a garbage collector, and so methods acquire and release are not needed. The JAVA programming 
language delivers basic types by value and non-basic types by reference. All calls are specified by value except inter- 

3 5 faces. In a JAVA environment, all non-basic types returned or delivered through out parameters are by value, which 
means that the implementation must copy any non-basic types before return or deliver. 

[0096] In a C++ environment, for example, interfaces are mapped to pure virtual classes. To automatically control 
the lifetime of interfaces a template called "Reference" is used. All return, parameter and member types are "Refer- 
ences" (e.g.: Reference< Xlnterface >). The "Reference" acquires the interface when it is constructed, and releases 
40 the interface when it is destructed. 

Structure: 

[0097] A structure is a collection of elements. The type of each element is fixed and it cannot be changed. The 
45 number of elements is fixed. 

Exceptions: 

[0098] An exception is a program control construct besides the normal control flow. One major feature of exceptions 
so is that with exceptions, implementation of the error handling is simpler. Exceptions are similar to structures since ex- 
ceptions are also a collection of elements and each type of each element is fixed and cannot be changed and the 
number of elements is also fixed. An additional feature of exceptions is that exceptions can be thrown by a method. 
All exceptions, which can be thrown by a method, must be declared at the method, except for the exception Runtime- 
Exception, which always can occur. All exceptions must be derived from interface Exception in the UNO environment. 
55 (See commonly filed and commonly assigned European Patent Application, entitled "A NETWORK PORTAL SYSTEM 
AND METHODS" of Matthias Hiitsch, Ralf Hofmann and Kai Sommerfeld (Attorney Docket No. 85880), which is in- 
corporated herein by reference in its entirety. If an exception is declared at a method, the method is allowed to throw 
all derived exceptions. The caller of a method must respond to this behavior. 
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[0099] In the JAVA environment, for example, all exceptions are derived from exception java.lang. Exception. The 
exceptions are declared at the methods. In the C++ environment, for example, the exceptions are generated as struc- 
tures. An exception is thrown as an instance (e.g.: throw RuntimeExceptionQ). At the other side, the exception should 
be caught as a reference (...catch(RuntimeException & ){...}). 

Union: 

[0100] A union contains one element. The declaration of a union specifies the possible types. 
Array: 

[0101] An array contains any number of elements. The type of the elements is fixed and cannot be changed. 
Any: 

[0102] An any contains one element. All types of elements are possible. An any contains a reference to the value 
and the type description of the type. With the type description, the bridge can transform the value, if necessary. In the 
JAVA environment, the any is, for example, represented by class Any, which contains a class as type description and 
a value, which is "java.lang. Object". The basic types are wrapped to their proper classes. For example, a Boolean 
value is an object of the class "java.lang. Boolean", which contains the value. 

[0103] In the C++ environment, the any is represented through class Any. Each type generated by a C++ code maker 
implements a function "getCppuType". This function is used to implement the template access operators "«=" and 
"»=". These operators insert and extract the value of the any. 

Sequence: 

[0104] A sequence is a generic data type. A sequence contains the number of elements and the elements. In the 
JAVA environment, the specification of an array fulfills this specification. This is not true for the C++ environment. An 
array in the C++ programming language does not contain the number of elements. It is not possible to return a C++- 
array, e.g., Char[] getName() is not possible. It is difficult to manage the lifetime between the called and the caller, if 
only a pointer is returned. Therefore, in the C++ programming language, a sequence is a template with the name 
Sequence. The implementation contains a pointer to a structure, which contains a pointer to the elements, the number 
of elements and the reference count. Thus, the implementation of the template holds the binary specification. It is 
cheap to copy this sequence, because only the reference count is incremented. 

Creating and using a Proxy Interface 

[0105] With this understanding of an execution environment, and the various types that may be associated with an 
execution environment, a description of making and using one embodiment of a bridge including a proxy interface is 
now described. A bridge includes two mappings. Each mapping is dependent upon the counterpart mapping, because 
performing a call may require conversion of interfaces from one environment to the other environment, e.g., input 
parameters to an interface, and/or return values from an interface. Thus, a bridge implements infrastructure to exchange 
interfaces between two environments and is bidirectional. 

[0106] Figure 4 is a sequence diagram for one embodiment the present invention. Along the horizontal axis are 
individual objects, where each object is represented as a labeled rectangle. For convenience, only the objects needed 
to explain the operation are included. The vertical axis represents the passage of time from top to bottom of the page. 
Horizontal lines represent the passing of messages between objects. A dashed line extends down from each rectangle, 
and a rectangle along the dashed line represents the lifetime of the object. 

[0107] To make calls to a first binary specification for an execution environment the execution environment has to 
be denominated. In one embodiment, an execution environment is denominated by a string, because the string is 
extensible and the risk of double names is low. Example of strings used to denominate execution environments are 
presented in Table 6. 
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TABLE 6.: 



5 



10 



EXAMPLES OF STRINGS USED TO DENOMINATE EXECUTION ENVIRONMENTS 


LANGUAGE BINDING OR OBJECT MODEL 


NAMING 


Binary UNO 


uno 


JAVA 


java 


MICROSOFT C++ 4.2 -6.0 


msci 


EGCS 2.9.1 with RTTI 


egcs29 


Workshop Compiler 5.0 


sunpro5 


COM 


com 



[0108] Each bridge is implemented in a separate shared library that is loaded at runtime. One naming scheme of 
the library is a concatenation as follows: 



[purposeJSourceEnvName_DestEnvName 

[01 09] The optional purpose denotes the purpose of the bridge, e.g. , protocoling traffic between two environments. 
If no purpose is given, the bridge maps interfaces from the source environment to the destination environment. 
[0110] Hence, in this embodiment, user object 401 calls a method GetEnvironment, with a string denominating the 
source environment as a parameter, in runtime library 402. In response to the call, a source environment object 403 
is instantiated and registered by runtime library 402. 

[01 1 1 ] User object 401 calls a method GetEnvironment, this time with a string denominating the destination environ- 
ment as a parameter, in runtime library 402. In response to this call, a destination environment object 404 is instantiated 
and registered by runtime library 402. 

[0112] Next, user object 401 calls a method getMapping in runtime library 402. A first parameter in the method call 
is the string denominating the source environment. A second parameter in the method call is the string denominating 
the destination environment. 

[0113] In response to the call to method getMapping, a bridge object 405 is activated by runtime library 402. In one 
embodiment, a shared library is searched to find a library that contains a proxy factory for the specified source and 
destination environments. In a JAVA execution environment, the search is for a class with a name associated with the 
source and destination environments. The shared bridge library cannot be unloaded while any of its code is still needed. 
So both mappings and any wrapped interface (proxy) that are exported need to modify a shared bridge library wide 
reference count. If the shared bridge library can be unloaded the reference count goes to zero. 
[0114] After bridge object 405 is activated, user object 401 issues a call to a method Mapping. maplnterface with a 
first parameter that is a source interface, and a second parameter that is a type. After receiving the call to method 
Mapping. maplnterface, bridge object 405 issues a call to method so urceEnv.getObject Identifier of source environment 
object 403 for the type. An object identifier is returned for the type. e.g. , for an interface, and bridge object 405 issues 
a call to method destEnv.getRegisteredlnterface of destination environment object 404 with the object identifier and 
the type as input parameters. 

[0115] If a proxy interface is registered in destination environment object 404 for this object identifier and type, a 
pointer to the proxy is returned by method getRegistered Interface. In this example, a pointer to the proxy interface 406 
is returned to user object 401 . 

[0116] Conversely, if method get Registered Interface failed to find a registered proxy interface, bridge object 405 
calls method create proxy with a source environment and a type as input parameters. In creating a proxy bridge object 
405, in one embodiment, uses a proxy factory to generate method code to implement each method specified in the 
interface to be created. The only information to do this is a type description of the interface. For example, in a JAVA 
environment, a binary class file (*. class) is generated and loaded with the class loader. In the absence of a loader, 
which can directly load binary classes, a loader has to be provided. In a C++ environment, virtual method tables are 
generated, which delegate each call to the interface in the source environment. 

[0117] The knowledge of the type description is necessary to create the proxy, as described. This type description 
is the full description of the limited functionality, e.g., a description of an interface, in the source execution environment. 
The type description may refer one of the different types shown in Table 5. 

[01 1 8] Following creation of the proxy, bridge object 405 registers the interface with source environment object 403 
and registers the proxy interface with destination environment object 404. This completes creation of proxy interface 
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406, sometimes called proxy 406. 

[0119] To use proxy interface 406, user object 401 simply calls a method in proxy interface 406. In response to the 
call, proxy interface 406 converts any input parameters as necessary using the method type description, and marshals 
the arguments for source interface 407. Next, proxy interface 406 dispatches a call to the method in source interface 

5 407 in the source execution environment. 

[0120] The method is executed in the source environment and the results are returned by source interface 407 to 
proxy interface 406. Upon receiving a return for the call, proxy interface 406 checks for any exceptions and if there are 
none, converts any output parameters and the return value to the destination execution environment again using the 
method type description, and then returns the results to user object 401. Thus, user object 401 has transparently 

10 accessed functionality in another execution environment. Typically, this is limited functionality, as described above. 
[0121] In the following description, a specific example of a bridge that maps an interface from a MICROSOFT Visual 
C++ environment to a UNO environment is first described, and that maps an interface from a UNO environment to a 
MICROSOFT Visual C++ environment is described second. Table 7 is an example of a call to a method bar in the UNO 
interface XExample from a C++ program. 

15 

TABLE 7 . : EXAMPLE of C++ PROGRAM SEGMENT TO GENERATE 
20 and USE A PROXY 



Mapping aMapping ( "uno", "msci" ); 

XExample * pExample = (XExample *) 

aMapping . maplnterf ace ( pUnoExample, 

: : getCppuType ( (const Reference < XExample > *) 0 

) ) ; 



pExample->bar ( ) ; 



pExample->re lease ; 



45 

[01 22] For the example of Table 7, the initial call to function Mapping creates a bridge from the UNO environment to 
the MSCI environment. The generation of the bridge, in this example uses, methods initEnvironment and getMapping. 
Table 8 is the implementation of these methods that are used in the proxy class of Table 9, for this example. 

50 



55 



26 



EP1 122 644 A1 



TABLE 8.: EXAMPLE OF DECLARATION OF METHODS 
initEnvironment and getMapping. 



extern "C" SAL_DLLEXPORT void SAL_CALL 

uno_imtEnvironment ( uno_Environment * pCppEnv ) 

{ 

CPPU_CURRENT_NAMESPACE : : cppu_cppenv_initEnvironment ( 
pCppEnv ) ; 

} 

extern "C" SAL_DLLEXPORT void SAL_CALL 

uno_ext__getMapping ( uno_Mapping ** ppMapping, 
uno — Environment * pFrom, uno_Environment * pTo ) 

{ 

CPPU_CURRENT_NAMESPACE : : cppu_ext_getMapping ( ppMapping, 
pFrom, pTo ) ; 

} 



[0123] As explained above, to process a call to a method of a UNO interface in the C++ environment, there must be 
a proxy C++ object that delegates the method call to the corresponding UNO interface. Table 9 is bridge header file 
example of a bridge class, a C++ to UNO proxy class, and a UNO to C++ proxy class that can be modified for a specific 
environment. This example uses the bridge object and C++ to UNO proxy object that are instantiated using the classes 
in Table 9. As explained above, the call to method Mapping, map Interface creates a proxy interface. 
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TABLE 9.: EXAMPLE OF A CLASS DEFINITIONS 



namespace CPPU_CURRENT_NAME3PACE 

{ 

// these have to be defined in some C file in the 
// current namespace (See Tables 10 & 16) 
void SAL_CALL cppu_cpplnt er f aceProxy^patchVtable ( 
:: com: : sun: : star :: uno: .-XInterf ace * pCppI, 
typelib_Interf aceTypeDescript ion - pTypeDescr ) ; 
void SAL_CALL cppu_unoInt er f aceProxy_dispat ch ( 
uno_Interf ace * pUnoI, const 

typelib__TypeDescriplion * pMember Descr , void * 
pReturn, void * pArgs [] , uno_Any ppException ) 

struct cppu_J3ridge; 

struct cppu_Mapping : public uno__Mapping 

{ 

cppu_Bridge * pBridge; 

inline cppu__Mapping ( cppu_Bridye * pBr^dge, 
uno_MapInterf aceFunc fpMap ) ; 

} ; 

holding environments and mappings ===—==-—==— 
struct cppu_Bridge 



oslInterlockedCount 
uno_Ext Environment * 
uno_Ex tEnvironment * 
cppu^Kappi ng 
c p p u _ Mapping 
sal_Bool 

void SAL_CALL acquire (); 
void SAL CALL release 0; 



nRef ; 

pCppEnv; 

pUnoEnv; 

aCpp2Uno; 

aUno2Cpp; 

bExportCpp2Uno ; 
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inline cppu_Bridge ( uno_ExtEnvironment * pCppEnv_, 
uno_ExtEnvironment * pUnoEnv_, sal_Bocl 
bExportcpp2Uno_ ) ; 

}; 

//==-= a cpp proxy wrapping an uno interface 
struct cppu_cpplnterf aceProxy : public 
: :com: :sun: :sLar: :unu: :XInterface 



nRef ; 
pBridge ; 



oslInterlockedCount 
cppu__Bridge * 
// mapping information 

uno Interface * pUnoI; // wrapped interface 

typelib__Interf aceType Description * pTypeDescr; 

: : rtl: :OUString oid; 

// non virtual methods called on incoming vtable calls 

// ttl, #2 

inline void SAL_CALL acquireProxy ( ) ; 
inline void SAL_CALL releaseProxy ( ) ; 

// XInterface: these are only here for dummy , there 
will be a patched vtable! 

// dont use this, use cppu_querylnterf ace ( ) ! 

virtual : : com: : sun : : star : : uno : : Any SAL_CALL 

que ry Inter face ( const :: com: : sun :: star :: uno :: Type 
& ) { return :: com: : sun :: star :: uno :: Any () ; } 

// dont use this, use cppu_acquire ( ) ! 

virtual void SAL_CALL acquire () {} 

// dont use this, use cppu_release ( ) ! 

virtual void SAL CALL release () {} 



/ / ctor 

inline eppu cpplnterf aceProxy ( cppu_Bridge * pBridge , 
uno_Tnterf ace * pUnoI , 

typelib Inter faceTypeDescription * pTypeDescr__, 
const : : rtl : :OUString & rOId_ ); 

}; 

//= a uno proxy wrapping a cpp interface =— = 
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struct cppu^unoInterfaceProxy : public uno_Interf ace 



{ 

os 1 Inter 1 ockedCount 
cppu_Bridge * 



nRef ; 
pBridge ; 



// mapping information 

:: com: : sun :: star :: uno :: XInterf ace * pCppI; // 

wrapped interface 
typelib_Interf aceTypeDescr iption * pTypeDescr; 
: : rtl : : OUString oid; 

// ctor 

inline cppu_unoInterf aceProxy ( cppu_Bridge * pBridge_, 
: : com: : sun: : star : : uno : : XInterf ace * pCppI_ r 
typelib_Int erf aceTypeDescr iption * pTypeDescr_, 
const :: rtl :: OUString & rOId_ ); 

} ; 

/7 

inline void SAL_CALL cppu__cppenv_initEnvironment ( 

uno_Environment * pCppEnv ) ; 
// 

inline void SAL_CALL cppu_ext_getMapping ( unoJMapping 
ppMapping, uno__Environment * pFrom, 
uno_Environment * pTo ) ; 



45 [0124] The proxy object is instantiated and the vtable pointer is modified to give a generic vtable. For a MICROSOFT 
C++ environment, the generic vtable can be used because an objects' this pointer is at anytime the second stack 
parameter (See Fig. 6). However, for gcc orsunpro5 (See Table 6), the first parameter may the pointer to a struct return 
space. Thus, for there compilers, a vtable for each type that is used must be generated. 

[0125] As explained more completely below, when the proxy interface is called, a vtable index is determined by the 
50 generic vtable (See Figs. 7A and 7B), and based upon this index, the method type description is determined. This 
method type description is the information that is used to get the values from the processor call stack and perform a 
dispatch call on the target UNO interface that the C++ proxy is wrapping. 

[0126] After the dispatch call, the returned exception information is checked to determine whether a C++ exception 
has to be generated and raised. If no exception has occurred, the inout/out parameters are reconverted. In this example, 
55 the reconversion of inout/out parameters is only important for values representing interfaces or values containing in- 
terfaces, because the values of all objects in the UNO environment are binary compatible on a specific computing 
architecture. 

[0127] The C++ proxy, as defined by Table 9, holds the interface origin, i.e., the target UNO interface. Thus, the C++ 
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proxy can register with the C++ environment on the first execution of method acquire, and can revoke itself on its last 
execution of method release from its environment. 

[0128] The C++ proxy manages a reference count for the proxy, a pointer to the bridge of the C++ proxy to obtain 
the counterpart mapping, the UNO interface the C++ proxy delegates calls to, the (interface) type the C++ proxy is 
5 emulating, and an object identifier (oid). Thetypeand object identifier are needed to manage objects from environments, 
for proof of object identity, and to improve performance. A proxy to an interface is not needed if there is already a 
registered proxy for that interface. 

[0129] When the proxy object is created by the MICROSOFT Visual C++ compiler, the vtable is patched by the 
execution of method patchVtable. One embodiment of method patchVtable is presented in TABLE 10. 



TABLE 10.: EXAMPLE OF METHOD patchVtable 



55 



void SAL_CALL cppu_cpplnterf aceProxy_patchVtable ( 
XInterface * pCppI, 

typelib_InterfaceTypeDescription * pTypeDescr ) 

{ 

static MediateVtables * s_pMediateVtables = 0; 

if (! s_pMediateVtables) 

{ 

MutexGuard aGuard ( Mutex : : getGlobalMutex ( ) ); 

if (! s_pMediateVtables ) 

{ 

ttifdef L E AK_ST AT I C_DAT A 

s_pMediateVtables = new MediateVtables () ; 

#else 

static MediateVtables s_aMediateVtables ; 
s^pMediateVtables = &s_aMediateVtables ; 
#endif 



} 



(const void **)pCppI = spMediateVtables- 
>getMediateVtable ( pTypeDescr- 
>nMapFunction!ndexToMemberIndex ) ; 



} 



[0130] An embodiment of the class MediateVtables that is used to instantiate the object MediateVtables in method 
patchVtable is presented in TABLE 11 . 
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TABLE 11.: EXAMPLE OF CLASS MediateVtables 



class MediateVtables 
{ 

// 

struct DefaultRTTIEntry 
{ 

sal_Int32 _n0, _nl, _n2; 
type_info * jpRTTI; 
DefaultRTTIEntry ( ) 
: _n0( 0 ), 

_nl( 0 ), 

_n2( 0 ) 

{ _pRTTl = msci_getRTTI ( "com . sun . star . uno . XInterf ace" 
); } 

}; 

typedef list<void * > t_pSpacesList ; 
Mutex _aMutex; 
t_pSpacesList _aSpaces ; 

sal_Int32 ^Currents- 
const void * _pCurrent; 
public : 

const void * getMediateVtable ( sal_Int32 

nSize ) ; 

MediateVtables ( sal_Int32 nSize = 256 ) 
: __nCurrent ( 0 ) 
, __pCurrent ( 0 ) 
{ getMediateVtable ( nSize ); } 
-MediateVtables () ; 
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} ; 

// ; 

MediateVtables : : -MediateVtables ( ) 

{ 

TRACE ( "> calling -MediateVtables () : freeing mediate 

vtables . . . <\n M ) ; 
MutexGuard aGuard ( __aMutex )/ 

// this MUST be the absolute last one, which is called! 
for ( t_pSpacesList :: iterator iPos ( _aSpaces . begin ( ) ); 
iPos != _aSpaces . end ( ) ; ++iPos ) 

{ 

rtl_f reeMemory ( *iPos ) ; 
} " 

} 



[0131] TABLE 12 is an example of one embodiment of a method getMediateVtable that is called in the embodiment 
of method patchVtable of TABLE 10. 
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TABLE 12.: EXAMPLE OF METHOD getMediateVtable 



const void * MediateVtables :: getMediateVtable ( 
sal_Int32 nSize ) 

{ 

if (^nCurrent < nSize) 
{ 

TRACE ( "> need larger vtable! <\n M ); 
// dont ever guard each time, so ask twice when guarded 
MutexGuard aGuard( _aMutex ); 
if (_nCurrent < nSize) 
{ 

nSize = (nSize +1) & Oxfffffffe; 

char * pSpace = (char * ) rt l_allocateMemory ( 
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( (1+nSize) *sizeof (void *) ) + (nSize*12) ); 
_aSpaces . push_back ( pSpace ); 
// on index -1 write default rtti entry 
static Def aultRTTIEntry s_def ault Interf aceRTTI ; 
Mvoid **) pSpace = &s_def aultlnterf aceRTTI ; 
void ** pvft = (void **) (pSpace + sizeof (void *)); 
char * pCode = pSpace + ( (1+nSize) *sizeof (void *)); 
// setup vft and code 

for ( sal_Int32 nPos = 0; nPos < nSize; ++nPos ) 
{ 

unsigned char * codeSnip = (unsigned char *)pCode + 

(nPos *12) ; 
pvft[nPos] = codeSnip; 

f -k * 

* vtable calls detonate on these code snippets 
*/ 

// mov eax, nPos 
*codeSnip++ = 0xb8; 
*(sal_Int32 *) codeSnip = nPos; 
codeSnip += si zeo f ( sal_Int 32 ) ; 
// jmp rel32 cpp_vtable_call 
*codeSnip++ = 0xe9; 

*(sal_Int32 *) codeSnip - ((unsigned char 

* ) cpp_vtable_call ) - codeSnip - si zeof ( sal__Int32 ) ; 

\ 

_pCurrent = pSpace + sizeof (void *); 
_nCurrent - nSize; 
} 
} 

return __pCurrent; 
} 



[01 32] Figure 6 is an example of a call stack 600 of a virtual function call that is stored in a memory 61 0 of computer 
55 system 100 (Figs. 1A and 1B). The left-hand column is the stack offset for the start of storage location, and the right 
hand column gives the value stored at each storage location. 

[0133] The vtable for the C++ proxy, i.e., a function pointer array to perform polymorphic calls on C++ objects, de- 
termines which function should be called. Figure 7 A is an illustration of the vtable for this example that correlates the 
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slots in the table to the methods handled by the C++ proxy. Recall, that every proxy has to inherit the methods from 
UNO interface Xlnterface, which are methods acquire, release, and querylnterface. 

[0134] When the call to method bar (Table 7) is executed, the call is directed to the C++ proxy. The only task of the 
proxy vtable is to determine the call index of the UNO method that is to be called. (See Fig. 7B) 

5 [0135] Figure 8 is a process flow diagram of one embodiment of the operations performed by a proxy 130 or 130A 
that in this example is the C++ proxy. When method bar is called, process 800 (Fig. 8) is started in operation 801 . 
[0136] Initially, in determine slot operation 802 the C++ proxy executes method patchVtable (See Table 10) that in 
turn calls method get Mediate Vtable (See Table 12). Method getMediateVtable reaches an assembler snippet that 
determines the vtable slot of method bar and calls method vTable 81 0. This completes operation 802. 

10 [0137] TABLE 13 is an example of one implementation of method vTable 810. 
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TABLE 13.: AN EXAMPLE OF METHOD vTable 



/ * ± 

* is called on incoming vtable calls 

* (called by asm snippets) 
*/ 

static declspec (naked) void cdccl 

cpp vtable__call (void) 



a sir 



sub esp, 8 // space for 

immediate return type 
push esp 

push eax // vtable index 

mov eax, esp 

add eax, 16 

push eax // original stack ptr 

call cpp_mediate 

add esp, 12 

cmp eax, typelib_TypeClass_FLOAT 

je Lfloat 

cmp eax, t ypelib_TypeClass_DOUBLE 

je Ldouble 

cmp eax, typelib TypeClass_HYPER 

je Lhyper 

cmp eax, 
typelibJTypeClass_UNSIGNED__HYPER 

je Lhyper 
// rest is eax 

pop eax 

add esp, 4 
ret 
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Lhyper : 



pop 



eax 



pop 



edx 



ret 



Lf loat : 



fid 



dword ptr [esp] 
esp, 8 



add 



ret 



Ldouble : 



fid 



qword ptr [esp] 
esp, 8 



add 



ret 



[0138] Operation 802 transfers processing to prepare stack operation 811 in method mediate 81 0. In operation 811 , 

the stack space is prepared for register data, and then processing passes to call mediate operation 812. 

[01 39] Call mediate operation 812 calls method mediate that in turn looks up the called vtable index, gets the attribute 

or method type description, and calls a method that dispatches that actual call to the method in the UNO environment. 

A process flow diagram of one embodiment of method mediate 900 is presented in 

Figure 9. Table 14 is an example of method mediate. 

TABLE 14.: EXAMPLE OF METHOD mediate 



static typelib_TypeClass cdecl cpp_mediate ( void 

pCallStack, sal_Int32 nVtableCall , sal_Int64 * 
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pRegisterReturn /* space for register return */ ) 

{ 

OSL_ENSHURE( sizeof (sal_Int32 ) ==sizeof ( void *) , "### 

unexpected ! " ) ; 
// pCallStack: ret adr, this, [ret *], params 
10 // _this_ ptr is patched cppu_XInt erf aceProxy object 

cppu_cpplnterf aceProxy * pThis = static_cast< 

cppu_cpplnterf aceProxy * >( reinterpret_cast< 

XIntcrface * >( pCallStack [1 ] ) ); 
typelib_Interf aceTypcDescript ion * pTypeDescr = pThis- 

>pTypeDescr ; 
05L_ENSHURE( nVtableCall < pTypeDescr- 
20 >nMapFunctionIndexToMemberIndex r . "### illegal 

vtable index ! " ) ; 
if (nVtableCall >= pTypeDescr- 

>nMapFunctionIndexToMember Index) 

25 

{ 

throw RuntimeException ( OUString ( 

RTL_CONSTASCII_USTRINGPARAM ("illegal vtable 
so index!") ), (XInterface *)pThis ); 

I 

// determine called method 
sal_Int32 nMemberPos = pTypeDescr- 

35 

>pMapFunctionIndexToMemberIndex [nVtableCall] ; 
OSL_ENSHURE( nMemberPos < pTypeDescr->nAHMembers , "### 
illegal member index!" ); 
40 TypeDescription aMemberDescr ( pTypeDescr- 

>ppAllMembers [nMemberPos] ) ; 
typelib TypeClass eRet; 
45 switch (aMemberDescr . get ( ) ->eTypeClass) 

{ 

case t ypelib_TypeClass__INTERFACE_ATTRIBUTE : 

{ 

50 if (pTypeDescr- 

>pMapMemberIndexToFunctionIndex [nMemberPos ] == 
nVtableCall) 
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{ 

// is GET method 

eRet = cpp2uno_call ( pThis, aMember Descr . get ( ) , 
( ( typelib__lnterf aceAttributeType Description 
*) aMemberDescr . get ( ) ) ->pAttribut eTypeRef , 0, 0, 
1Q pCallStack, pRegisterReturn ) ; 

} 

else 
{ 

15 

// is SET method 

typelib_MethodParameter a Pa ram; 
aParam. pTypeRef 
20 =( ( typelib_Interf aceAttr ibuteTypeDescript ion 

* ) aMemberDescr . get ( ) ) ->pAttributeTypeRef ; 
aParam.bin - sal_True; 

aParam.bOut = sal_False; 

25 

eRet = cpp2uno_call ( pThis, aMember Descr , get () , 0 , 1, 
SaParam, pCallStack, pRegisterReturn ) ; 

} 

30 break ; 

} 

case typelib_TypeClass_INTERFACE_METHOD: 
{ 

35 

// is METHOD 

switch (nVtableCall) 

{ 

40 / / standard XInterface vtable calls 

case 1: // acquire () 

pThis->acquireProxy ( ) ; // non virtual call! 
45 eRet = typelib_TypeClass_VOID; 

break; 
case 2: // release)) 

pThis->releaseProxy ( ) ; // non virtual call! 
50 eRet = typelib_TypeClass_VOID; 

break; 

case 0: // querylnterf ace ( ) opt 
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{ 

typelib _TypeDescription * pTD = 0; 
5 TYPELIB_DANGER_GET ( &pTD, reint erpret__cas t< Type * >( 

pCallStackl3] ) ->get TypeLibType ( ) ) ; 
0SL_ASSER7 ( pTD ) ; 
10 XInterface * plnterface = 0; 

( *pThis->pBridge->pCppEnv->getRegisteredInterf ace) ( 
pThis->pBridge->pCppEnv, (void **) ^plnterface, 
pThis->oid . pData , 

15 

( typelib_Interf aceTypeDescript ion *)pTD ) ; 
if (plnterface) 
{ 

20 uno_any construct ( reinterpret_cast< uno^Any * >( 

pCallStack [2] ), Splnterface, pTD, cpp_acquire 
) ; 

pint erf ace->rclease ( ) ; 

25 

TYPELIB_DANGER_RELEASE ( pTD ); 
Mvoid ; pRegisterReturn = pCallStack [ 2 ] ; 
eRet = typelib_TypeClass_ANY; 
30 break; 
} 

TYPELIB_DANGER__RELEASE ( pTD ); 

} // else perform querylnt erf ace ( ) 

35 

default : 

eRet = cpp2uno_call ( 
pThis, aMemberDescr . get () , 
40 ( ( typelib__lnterf aceMethodTypeDescript ion 

* ) aMemberDescr. get ( ) ) ~->pReturnTypeRef r 
( (typelib_Interf aceMethodTypeDe script ion 
*) aMemberDescr. get () ) ->nParams, 

45 

( ( type liblnt erf aceMethodTypeDescript ion 
*) aMemberDescr. get ( ) ) ->pParams, pCallStack, 
pRegisterRe turn ) ; 

50 J. 

break; 
} 
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default : 
{ 

throw RuntimeExcept ion ( 

OUString( RTL_CONSTASCI I_USTRINGPARAM ( "no member 

description found!") ), (XInterface *)pThis ); 
// is here for dummy 
eRet - typelib__TypeClass_VOID; 

} 
} 

return eRet; 
} 



[0140] Method call check 901 of method mediate 900 determines whether the call is a method call. If the call is a 
method call processing transfers to acquire/release check operation 910, and otherwise to attribute get check operation 
920. 

25 [0141] Acquire/release check operation 910 branches to acquire/release call operation 911 if the method call is a 
call to either method acquire or method release, because these calls can be executed without calling the interface in 
the source environment. If the method call is not a call to either method acquire or method release, processing transfers 
from check operation 910 to query interface check operation 912. Acquire/Release call operation 911 performs the 
appropriate method, which is a non-virtual call, and returns. 

30 [0142] Query interface check operation 912 determines whether the method call is to method querylnterface. If the 
method call is not to method querylnterface, check operation 912 transfers to call Env1_to_Env2 with Interface oper- 
ation 930 and otherwise transfers to registered interface available check operation 913. In the current example, the 
call to method bar results in check operation 912 transferring to operation 930. 

[0143] Nevertheless, to complete the description of this branch of method mediate 900, if there is a registered inter- 
35 face in the source environment object for method querylnterface, check operation 913 transfers to set return value 
operation 914 and otherwise to call Env1_to_Env2 with Interface operation 930. Asking whether the interface is reg- 
istered in the source environment object is an optimization that eliminates a call to the actual interface in the source 
environment. Set return value operation 914 sets the registered interface as the return value and returns. 
[0144] If the call to the C++ proxy was not a method call, check operation 901 transfers to attribute get check operation 
40 920. In this embodiment, there is either an attribute get or an attribute set. If the call to the proxy is an attribute get, 
check operation 920 transfers to prepare attribute get call operation 921 and otherwise transfers to prepare attribute 
set call operation 922. Both operations 921 and 922 set up the parameters forthe call and transferto call Env1_to_Env2 
with Interface operation 930. 

[0145] An embodiment of method Env1_to_Env2 with interface forthe C++ proxy is presented in Table 15. Figure 
45 1 0 is a process flow diagram for one embodiment of method Env1_to_Env2 with interface. 
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TABLE 15.: AN EXAMPLE OF METHOD Envl__t o__Env2 with 

interface 



using namespace std; 
using namespace rtl; 
using namespace osl; 

using namespace com: : sun :: star :: uno ; 
namespace CPPU_CURRENT NAMESPACE 
{ 

static inline typelibJTypeClass cpp2uno_call ( 
cppu__cpplnterf aceProxy * pThis, const 
typelib__Type Description * pMemberTypeDescr , 
typelib^TypeDescriptionRef erence * pReturnTypeRef , 
sal_Int32 nParams, typel ibJMethodParameter * 
pParams, void ** pCallStack f 
sal_InL64 * pRegisterRet urn ) 

{ 

// pCallStack: ret, this, [complex return ptr] , params 
char * pCppStack = (char *) (pCallStack 4-2); 
// return 

typelibTypeDescription * pReturnTypeDescr = 0; 
if (pReturnTypeRef) TYPELIB_DANGER__GET ( 

^pReturnTypeDescr, pReturnTypeRef ) ; 
void * pUnoReturn = 0; 

// complex return ptr: if != 0 && != pUnoReturn, 

// reconversion need 

void * pCppReturn = 0; 

if (pReturnTypeDescr) 

{ 

if (cppu_isSimpleType ( pReturnTypeDescr )) 
{ 

// direct way for simple types 
pUnoReturn - pRegisterRet urn ; 
} 

else // complex return via ptr (pCppReturn) 
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{ 

pCppReturn = * (void ** ) pCppStack; 
pCppStack += sizeof (void *) ; 

pUnoReturn = (cppu_relatesToInterf ace ( pReturnTypeDescr 

) 

// direct way 
? alloca ( pReturnTypeDescr->nSize ) : pCppReturn); 

) 
} 

/ / stack space 

OSL_ENSHURE( sizeof (void *) == si zeof ( sal_Int 32 ) , "### 

unexpected size!" ); 
// parameters 

void pUnoArgs = (void ***)ailoca( 4 * sizeof (void *) 

* nParams ) ; 

void ** pCppArgs = pUnoArgs + nParams; 

// indices of values that have to be converted 

// (interface conversion cpp<=>uno) 

sal_Int32 * pTempIndizes = (sal_Int32 *) (pUnoArgs + (2 

* nParams) ) ; 

// type descriptions for reconversions 
typelib_TypeDescription ppTempParamTypeDescr = 

(typelibJTypeDescription **) (pUnoArgs + (3 * 

nParams ) ) ; 
sal_Int32 nTempIndizes = 0; 

for ( sal_Int32 nPos = 0; nPos < nParams; ++nPos ) 
{ 

const typelib_MethodParameter & rParam = pParams [nPos] ; 
typelibJIypeDescription * pParamTypeDescr = 0; 
TYPELIB_DANGER_GET ( ^pParamTypeDescr , rParam . pTypeRef 
) ; 

if (! rParam. bOut && cppu_isSimpleType ( pParamTypeDescr 
) ) // value 

{ 

pCppArgs [nPos] = pCppStack; 
pUnoArgs [nPos] = pCppStack; 
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switch (pParamTypeDescr->eTypeClass) 

{ 

case typelib__TypeClass_HYPER: 

case typelib_TypeClass_UNSIGNED_HYPER: 

case typelib_TypeClass_DOUBLE: 

pCppStack += sizeof ( sal__Int 32 ) ; // extra long 

} 

// no longer needed 

TYPELIB_DANGER_RELEASE ( pParamTypeDescr ); 
} 

else // ptr to complex value I ref 

{ 

pCppArgs [nPos] = * (void ** ) pCppStack; 

if (! rParam.bin) // is pure out 

{ 

// uno out is unconstructed mem! 

pUnoArgs [nPos] = alloca ( pParamTypeDescr->nSi ze ); 
pTempIndizes [nTempIndi zes ] = nPos; 
// will be released at reconversion 

ppTempParamTypeDescr [ nTempIndi zes++ ] - pParamTypeDescr 
} 

// is in/inout 

else if [cppu_relatesToInterface ( pParamTypeDescr )) 
{ 

uno copyAndConvertData ( pUnoArgs [nPos] = alloca ( 

pParamTypeDescr->nSize ), * (void ) pCppStack, 
pParamTypeDescr, &pThis->pBridge->aCpp2Uno ) ; 

// has to be reconverted 

pTempIndizes [nTempIndizes] = nPos; 

// will be released at reconversion 

ppTempParamTypeDescr [nTempIndizes++ ] = pParamTypeDescr 
} 

else // direct way 
{ 

pUnoArgs [nPos] = * (void * *) pCppStack ; 
// no longer needed 



45 



EP1 122 644 A1 



TYPELIB_DANGER_RELEASE ( pParamTypeDescr ); 

} 

} 

// standard parameter length 
pCppStack += sizeof ( sal_Int32 ) ; 
> 

// Except ionHolder 

uno_Any aUnoExc; // Any will be constructed by callee 
uno^Any * pUnoExc = SaUnoExc; 
// invoke uno dispatch call 

( *pThis->pUnoI->pDispatcher ) ( pThis->pUnoI , 

pMemberTypeDescr , pUnoReturn, pUnoArgs, SpUnoExc 

) ; 

// in case an exception occurred. , . 

i f (pUnoExc) 
{ 

// destruct temporary in/inout params 

while (nTempIndi zes— ) 

{ 

sal_Int32 nlndex = pTempIndi zes [ nTempIndi zes ] ; 
// is in/inout => was constructed 
if (pParams [nlndex] .bin) 
uno^destructData ( pUnoArgs [nlndex] , 

ppTempParamTypeDescr [nTempIndi zes ] , 0 ) ; 
TYPELIB_DANGER_RELEASE ( 

ppTempParamTypeDescr [nTempIndi zes ] ) ; 

} 

if (pReturnTypeDescr) TYPELIB DANGER_RELEASE ( 

pReturnTypeDescr ) ; 
msci_raiseException ( &aUnoExc, &pThis->pBridge- 

>aUno2Cpp ) ; // has to destruct the any 
// is here for dummy 
return typelib_TypeClass_VOID; 
} 

else // else no exception occurred. . . 
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{ 

// temporary params 
while (nTempIndizes-- ) 
{ 

sal_Int32 nlndex = pTempIndizes [nTempIndizes] ; 
typelib_TypeDescript ion * pParamTypeDescr = 

ppTempParamTypeDescr [nTempIndizes ] ; 
if (pParams [nlndex] .bOut) // inout/out 
{ 

// convert and assign 

uno_destructData ( pCppArgs [nlndex] , pParamTypeDescr 

cpp_release ) ; 
uno_copyAndConvertData ( pCppArgs [nlndex] , 

pUnoArgs [nlndex] , pParamTypeDescr, &pThis- 

>pBridge->aUno2Cpp ) ; 

} 

// destroy temp uno param 

uno_destructData ( pUnoArgs [nlndex] , pParamTypeDescr 
) ; 

TYPELIB_DANGER_RELEASE ( pParamTypeDescr ); 
} 

// return 

if (pCppReturn) // has complex return 
{ 

if (pUnoReturn != pCppReturn) // needs reconversion 
{ 

uno_copyAndConvertData ( pCppReturn, pUnoReturn, 

pReturnTypeDescr , &pThis->pBridge->aUno2Cpp ) ; 
// destroy temp uno return 

uno_destructData ( pUnoReturn, pReturnTypeDescr, 0 ) 
} 

// complex return ptr is set to eax 

* (void **) pRegisterReturn = pCppReturn; 

} 

if (pReturnTypeDescr) 
{ 
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typelib_TypeClass eRet = 

( typeiib__TypeClass) pReturnTypeDescr->eTypeClass ; 
TYPELIB__DANGER_RELEASE ( pRet urnTypeDescr ); 
return eRet; 
} 

else 

return t ypel ib_TypeClass_VOI D; 

} 

} 



20 [0146] In Figure 10, read parameters operation 1001 reads the parameters from the stack. All simple parameters 
are directly accessed on the stack (up to eight bytes). All complex structures, e.g., interfaces, are referenced by a 
pointer. Since in this example UNO and C++ types have the same binary size (See Table 5), only interfaces need to 
be exchanged. 

[0147] Read parameters operation 1 001 transfers to convert parameters operation 1 002. Convert parameters oper- 
as ation 1 002, using the parameter type description, converts the parameters read to the UNO environment and transfers 
to allocate memory operation 1 003. Allocate memory operation 1 003 allocates memory for the out parameters returned 
by the call to the UNO interface, and for the return value. Allocate memory operation 1003 transfers processing to 
dispatch call operation 1004. 

[0148] Dispatch call operation 1004 calls, in this example, method bar in UNO interface XExample. In general, dis- 
30 patch call operation 1004 dispatches a call to the source interface (See Fig. 4). The call is executed in the source 
environment and the results, if any ; are returned to operation 1004 that in turn transfers to exception check operation 
1005. 

[0149] Exception check operation 1005 determines whether an exception was thrown in response to the call. If an 
exception was thrown, check operation 1005 transfers processing to clean up operation 1110 and otherwise processing 
35 transfers to convert parameters operation 1020. 

[01 50] Clean up operation 1010 cleans up any temporary parameters that were created in the call in operation 1 004. 
Operation 1010 transfers to throw exception operation 1030 that in turn throws an exception in the destination envi- 
ronment based upon the exception received from the call to the source environment. 

[0151] If an exception was not thrown in the source environment, convert parameters operation 1020 converts any 
40 parameters that were returned from operation 1 004, e.g., out parameters and/or inout parameters using the parameter 
type description, from the source environmentto the destination environment, and transfers to clean up operation 1 021 . 
Clean up operation 1021 cleans up any temporary parameters that were created in the call in operation 1004 and 
transfers to convert return value operation 1 022. Operation 1 022 converts any return valuefrom the source environment 
to the destination environment so that both the return value and any returned parameters are written back, in this 
45 example to C++. Processing returns to mediate method 900 that in turn returns to fill return registers 813 in method 
vTable810. 

[0152] In fill return registers operation 813, if the type is one of float, double, hyper, or unsigned hyper, an appropriate 
action is taken to properly fill the return registers. Otherwise, a 32-bit integer is placed in register eax. See Table 13 
for one embodiment of operation 813. 

50 [0153] The above example assumed that the original call was in a C++ environment and was directed to a method 
of an interface in the UNO environment. In the embodiment of Figure 1 A, another possibility is that a call is made in 
the UNO environment, i.e., environment 120 to a C++ method in environment 150. In this case, the bridge and proxy 
would be in the UNO environment. Alternatively, in Figure 1B, the intermediate environment is a UNO environment. 
[0154] In this embodiment, struct cppu_unolnterface Proxy in Table 9 is used to instantiate the UNO proxy that wraps 

55 a C++ interface. As explained more completely below, when the proxy interface is called, a check is made to determine 
if a method of the proxy interface has been called. If a method was called, any input parameters are converted using 
the type description and pushed on a processor stack, and then a call is dispatched to the demanded vtable slot in the 
source interface. 
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[0155] After execution of the dispatch call, the returned information is checked to determine whether a C++ exception 
was generated. If no exception has occurred, the inout/out parameters are reconverted. In this example, the reconver- 
sion of inout/out parameters is only important for values representing interfaces or values containing interfaces, be- 
cause the values of all objects in the UNO environment are binary compatible on a specific computing architecture. 
[01 56] The UNO proxy, as defined by Table 9, holds the interface origin, i.e., the target C++ interface. Thus, the UNO 
proxy can register at with the UNO environment on the first execution of method acquire, and can revoke itself on its 
last execution of method release from its environment. 

[0157] The UNO proxy manages a reference count for the proxy, a pointer to the bridge of the UNO proxy to obtain 
the counterpart mapping, the C++ interface the UNO proxy delegates calls to, the (interface) type the UNO proxy is 
emulating, and an object identifier (oid). Thetype and object identifier are needed to manage objects from environments, 
for proof of object identity, and to improve performance. A proxy to an interface is not needed if there is already a 
registered proxy for that interface. 

[0158] When the call to a method in the wrapped C++ interface is executed, the call is directed to the UNO proxy. 
Figure 11 is a process flow diagram of one embodiment of the operations performed by the UNO proxy. One example 
of computer code for this embodiment is presented in TABLE 1 6. 
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TABLE: 16.: EXAMPLE OF A METHOD dispatch USED BY A UNO 
PROXY WRAPPING A C++ INTERFACE 



void SAL_CALL cppu_unoInterf aceProxy_dispatch ( 
uno_Interf ace * pUnoI, const 

typelibJTypeDescription * pMemberDescr, void * 
pReturn, void * pArgsf], uno_Any ppException ) 

{ 

// is my surrogate 

cppu_unoInterf aceProxy * pThis = stat ic__cast< 

cppu_unoInterf aceProxy * >( pUnol ); 
typelib_Interf aceTypeDescript ion * pTypeDescr = pThis- 

>pTypeDescr ; 

switch (pMemberDescr->eTypeClass) 
{ 

case typelib__TypeC las s_INTERFACE_ATTRI BUTE : 
{ 

// determine vtable call index 
sal_Int32 nMemberPos = 

( (typelib_Interf aceMemberType Description 

* ) pMemberDescr ) ->nPosition; 
OSL_ENSHURE( nMemberPos < pTypeDescr->nAl lMcmber s , "### 

member pos out of range!" ); 
sal__Int32 nVtableCall = pTypeDescr- 

>pMapMeraberIndexToFunctionIndex [nMemberPos] ; 
OSL_ENSHURE( nVtableCall < pTypeDescr- 

>nMap Functi on IndexToMember Index, "### illegal 

vtable index ! 11 ) ; 
typelib_TypeDescriptionRef erence * pRunt imeExcRef = 0; 
if (pReturn) 
{ 

// dependent dispatch 
cpp_call( pThis, nVtableCall, 
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( (typelib Interf aceAttr ibuteTypeDescript ion 
* ) pMemberDescr) ->pAttributeTypeRef , 

0, 0, // no parans 

1, &pRuntimeExcRef , // Runt imeExcept ion 
pReturn, pArgs, ppException ) ; 

} 

else 

{ 

// is SET 

typelib_MethodParameter a Pa ram; 
aParam. pTypeRef = 

( (typelib_Int erf aceAttr ibuteTypeDescript ion 

* ) pMemberDescr) ->pAttributeTypeRef ; 
aParam.bin = sal_True; 

aParam.bOut = sal_False; 

typelib_TypeDescriptionRef erence * pReturnTypeRef = 0 
OUString aVoidName ( RTL_CONSTASCI I_USTRINGPARAM ( " void 
) ; 

Typelib t y pedes crip tionref er ence_new ( SpReturnTypeRef , 
typelib_TypeClass_VOID, aVoidName . pData ) ; 

// dependent dispatch 

cpp_call ( pThis, nVtableCall +1, // get, then set 
method 

pReturnTypeRef, 
1, &aParam, 
1 , &pRuntimeExcRef , 
pReturn, pArgs, ppException ) ; 
typelib t ypedescr iptionref erence__release ( 
pReturnTypeRef ) ; 
} 

break; 
} 

case typelib_TypeClass_INTERFACE_METHOD: 
{ 

// determine vtable call index 
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sal_Int32 nMemberPos = 

( ( type liblnt erf aceMemberTypeDe script ion 

* ) pMemberDescr ) ->nPosition; 
OSL_ENSHURE ( nMemberPos < pTypeDescr->nAllMembers , "### 

member pos out of range ! " ) ; 
sal_Int32 nVtabieCall = pTypeDescr- 

>pMapMemberIndexToFunctionIndex [nMemberPosl ; 
OSI.._F.NSHURF. ( nVtabieCall < pTypeDescr- 

>nMapFunct ion TndexToMember Index, " ### illegal 

vtable index ! " ) ; 
switch (nVtabieCall) 
{ 

// standard calls 

case 1 : // acquire uno interface 
( *pUnoI->acquire) ( pUnoI ); 
*ppException = 0; 
break; 

case 2 : // release uno interface 
( A pUnoI->release) ( pUnoI ); 
*ppException = 0; 
break; 

case 0: // querylnt erf ace ( ) opt 

{ 

typelib_TypeDescription * pTD = 0; 

TYPELIB_DANGER_GET ( &pTD, reinterpret_cast< Type * >( 
pArgs[0] ) ->getTypeLibType ( ) ); 

OSL_ASSERT ( pTD ) ; 

uno_Inter f ace * plnterface = 0; 

(*pThis->pBridge->pUnoEnv- 

>getRegisteredInterf ace) (pThis->pBr idge->pUnoEnv, 

(void **) &plnterf ace, pThis->oid . pData , 

( typelib_Interf aceTypeDescript icn *)pTD ) ; 

if (plnterface) 

{ 

uno_any_construct ( reint erpret_cast < uno_Any * > ( 
pReturn ) , ^plnterface, pTD, 0 ) ; 
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( *plnterf ace->release) ( plnterface ); 
TYPELIB_DANGER_RELEASE ( pTD ); 
"^ppException - 0; 
break; 

} 

TYPELIB_DANGER_RELEASE ( pTD ); 

} // else perform querylnterf ace ( ) 

default : 

// dependent dispatch 
cpp_call( pThis, nVtableCall, 

( ( t ype 11 b_Interf aceMethodTypeDe script ion 

* ) pMemberDescr ) ->pReturnTypeRef , 

( (typelib_Int erf aceMethodTypeDe script ion 

* ) pMemberDescr) ->nParams, 

( ( typelib_I nt erf aceMethodTypeDe script ion 

* ) pMemberDescr ) ~>pParams , 

( ( type lib_Int erf aceMethodTypeDe script ion 

* ) pMemberDescr) ->nExceptions, 

( ( typelib_InterfaceMethodTypeDescription 

* ) pMemberDescr) ->ppExcept ions , pReturn, pArgs, 

ppException ) ; 
} 

break; 

} 

default : 

{ 

: : com: : sun: : star: : uno : : Runt imeExcept ion aExc (OUString ( 
RTL_CONSTASCII_USTRINGPARAM ("illegal member type 
description!") ) , pThis->pCppI ); 

typelrb_TypeDescription * pTD = 0; 

const Type & rExcType = : : getCppuType ( (const 

: : com: : sun :: star : : uno : : Runt imeExcept ion * ) 0 ) ; 

TYPELIB__DANGER_GET ( &pTD, rExcType . getTypeLibType ( ) ) ; 

uno_any_construct ( ^ppException, &aExc, pTD, 

0 ) ; 

TYPELIB_DANGER__RELEASE ( pTD ); 
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} 

} 



10 

[01 59] Method call check 1101 of method dispatch 1 1 00 determines whether the call is a method call. If the call is a 
method call processing transfers to acquire/release check operation 1110, and otherwise to attribute get check oper- 
ation 1120. 

[01 60] Acquire/release check operation 1110 branches to acquire/release call operation 1111 if the method call is a 
*5 call to either method acquire or method release, because these calls can be executed without calling the interface in 
the second environment. If the method call is not a call to either method acquire or method release, processing transfers 
from check operation 1 1 1 0 to query interface check operation 1112. Acquire/Release call operation 1111 performs the 
appropriate method, which is a non-virtual call, and returns. 

[0161] Query interface check operation 1112 determines whether the method call is to method querylnterface. If the 
20 method call is not to method querylnterface, check operation 1112 transfers to call Env2_to_Env1 with Interface oper- 
ation 1130 and otherwise transfers to registered interface available check operation 1113. 

[0162] If there is a registered interface in the source environment for method querylnterface, check operation 1113 
transfers to set return value operation 1114 and otherwise to call Env2_to_Env1 with Interface operation 1130. Set 
return value operation 1114 sets the registered interface as the return value and returns. 

25 [0163] If the call to the C++ proxy was not a method call, check operation 1101 transfers to attribute get check 
operation 1120. In this embodiment, there is either an attribute get or an attribute set. If the call to the UNO proxy is 
an attribute get, check operation 1120 transfers to prepare attribute get call operation 1121 and otherwise transfers to 
prepare attribute set call operation 1 1 22. Both operations 1 1 21 and 1 1 22 set up the parameters for the call and transfer 
to call Env2_to_Env1 with Interface operation 1130. The call is given the C++ interface pointer, a vtable index, and all 

30 parameters necessary to perform the C++ virtual function call. 

[0164] An embodiment of method Env2_to_Env1 with interface for the UNO proxy is presented in Table 17. Figure 
12 is a process flow diagram for one embodiment of method Env2_to_Env1 with interface. 



TABLE 17.: EXAMPLE of METHOD Env2__to_Envl with 
interface FOR THE UNO PROXY 



namespace CPPU__CURRENT_NAMESPACE 
{ 

inline static void cpp_call (cppu_unoInterf aceProxy * 
pThis, sal_Int32 nVtableCall, 

typelib_TypeDescriptionRef erence * pReturnTypeRef , 
sal__Int32 nParams, typelib_MethodParameter * 
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pParams, sal_Int32 nExceptions, 
typelib TypeDescriptionRef erence 
ppExceptionRef s, void * pUnoReturn, void * 
pUnoArgs[], uno_Any ppUnoExc ) 

{ 

// max space for: [complex ret ptr] , values |ptr ... 
char * pCppStack = (char *)alloca( sizeof ( sal_Int 32 ) + 

(nParams * si zeof ( sal_Int 64 ) ) ); 
char * pCppStackStart = pCppStack; 
// return 

Lypelib_TypeDescription * pReturnTypeDescr = 0; 
TYPELIB_DANGER__GET ( SpReturnTypeDescr , pRet urnTypeRef 
) ; 

OSL_ENSHURE ( pReturnTypeDescr, "### expected return 

type description!" ); 
//it != 0 && != pUnoReturn, needs reconversion 
void * pCppReturn = 0; 
if (pReturnTypeDescr) 
{ 

if (cppu_isSimpleType ( pReturnTypeDescr )) 
{ 

pCppReturn = pUnoReturn; // direcL way for simple types 



else 



// complex return via ptr 

// direct way 

pCppReturn = * (void **) pCppStack = 

(cppu_relatesToInterf ace ( pReturnTypeDescr ) ? 

alloca( pReturnTypeDescr->nSize ) : pUnoReturn); 
pCppStack += sizeof (void *); 



) 

// stack space 

OSL_ENSHURE( sizeof (void *) == sizeof ( sal_Int 32 ) , "### 
unexpected size!" ); 
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/ / args 

void ** pCppArgs = (void **)alloca( 3 * sizeof (void *) 
* nParams ) ; 

// indices of values thats have to be converted 
// (interface conversion cpp<=>uno) 

sal_Int32 * pTempIndizes = (sal_Int32 *) (pCppArgs + 
nParams) ; 

// type descriptions for reconversions 
typelib_TypeDescription * * ppTempParamTypeDescr = 

( typelib_TypeDescription **) (pCppArgs + (2 * • 

nParams ) ) ; 
sal_Int32 nTempIndizes ^ 0; 

for ( sal_Int32 nPos = 0; nPos < nParams; ++nPos ) 
{ 

const typelib_MethodParameter & rParam = pParams [nPos ] ; 

typelibTypeDescription * pParamTypeDescr = 0; 

TYPELI B_DANGER_GET ( ^pParamTypeDescr , r Param. pTypeRef 

) ; 

if (! r Param. bOut & & cppu_isSimpleType ( pParamTypeDescr 



) ) 



{ 



uno_copyAndConvert Data ( pCppArgs [nPos ] - pCppStack, 

pUnoArgs [nPos ] , pParamTypeDescr, &pThis->pBr idge- 
>aUno2Cpp ) ; 

switch (pParamTypeDescr->eTypeClass ) 

{ 

case typelib_TypeClass_HYPER: 

case typeiib_TypeClass_UNSIGNED_HYPER: 

case typelib_TypeClass_DOUBLE : 

pCppStack += sizeof (sal_Int32) ; // extra long 

} 

// no longer needed 

TYPEL1B_DANGER_RELEASE ( pParamTypeDescr ); 
} 

else // ptr to complex value | ref 
{ 



55 



56 



EP1 122 644 A1 



if (! rParam.bin) // is pure out 
{ 

// cpp out is constructed mem, uno out is not! 
uno_constructData( * (void ** ) pCppStack = 

pCppArgs [nPos] = alloca ( pParamTypeDescr->nSize ) 

pParamTypeDescr ) ; 
pTempIndizes [nTempIndizes] = nPos; 
// default constructed for cpp call 
// will be released at reconversion 

ppTempParamTypeDescr [nTempIndizes++] - pParamTypeDescr 
} 

// is in/inout 

else if (cppu_relatesToInterface ( pParamTypeDescr )) 
{ 

uno_copyAndConvertData ( * (void **) pCppStack = 

pCppArgs [nPos] = alloca ( pParamTypeDescr->nSize ) 
pUnoArgs [nPos] , pParamTypeDescr, &pThis->pBr idge 
>aUno2Cpp ) ; 

pTempIndizes [nTempIndizes] - nPos; 

// has to be reconverted 

// will be released at reconversion 

ppTempParamTypeDescr [nTempIndizes++ ] = pParamTypeDescr 
} 

else // direct way 
{ 

* (void **) pCppStack = pCppArgs [nPcs] - pUnoArgs [ nPos ] ; 
// no longer needed 

TYPELIB DANGER RELEASE ( pParamTypeDescr ); 



pCppStack += sizeof (sal_Int32) ; // standard parameter 
length 

} 

// only try-finally/ try-except statements possible.., 

try 

{ 
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_try 
{ 

// pCppI is msci this pointer 

caiiVirtualMethod ( pThis->pCppI , nVtableCall, 
pCppReturn, pReturnTypeDescr->eTypeCiass , 
(sai_Int32 * ) pCppStackStart , (pCppStack - 
pCppStackStart) / si zeof ( sal_Int 32 ) ); 

// NO exception occured. . . 

*ppUnoExc = 0; 

// reconvert temporary params 

while (nTempIndizes-- ) 

{ 

sal_Int32 nlndex = pTempIndizes [nTempIndizes] ; 
Lypel i b__TypeDescr ipt ion * pParamTypeDescr = 

ppTempParamTypeDescr [nTempIndizes ] ; 
if (pParams [nlndex] .bin) 
{ 

if (pParams [nlndex] .bOut) // inout 
{ 

uno_destructData ( pUnoArgs [nlndex] , pParamTypeDescr 

) ; // destroy uno value 
uno_copyAndConvertData ( pUnoArgs [nlndex] , 

pCppArgs [nlndex] , pParamTypeDescr, &pThis- 

>pBridge->aCpp2Uno ) ; 

} 
} 

else // pure out 
{ 

uno__copyAndConvertData ( pUnoArgs [nlndex] , 

pCppArgs [nlndex] , pParamTypeDescr, &pThis- 
>pBridge->aCpp2Uno ) ; 

} 

// destroy temp cpp pa ram cpp: every param was 
// constructed 

uno_destructData ( pCppArgs [nlndex] , pParamTypeDescr 
cpprelease ) ; 
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TYPELI B_DANGER_RELEASE ( pParamTypeDescr ); 
} 

// return value 

if (pCppReturn && pUnoReturn != pCppReturn) 
{ 

uno_copyAndConvert Da ta ( pUnoReturn, pCppReturn, 

pReturnTypeDescr , 
&pThis~>pBridge->aCpp2Uno ) ; 

uno__destructData ( pCppReturn, pReturnTypeDescr, 
cpp_release ) ; 

} 
} 

except (msci_f ilterCppException ( 

GetExceptionlnf ormation () , *pp(JnoExc, &pThis- 

>pBridge->aCpp2Uno ) ) 

{ 

// *ppUnoExc is untouched and any was constructed by 

// filter function finally block will be called 

return; 



__f inally 

{ 

// cleanup of pararns was already done in reconversion 

// loop if no exception occured; this is quicker than 

// yelling all param descriptions twice! so cleanup 

// only if an exception occured: 

if (*ppUnoExc) 



// temporary pararns 
while (nTempIndizes-- ) 
{ 

sal_Int32 nlndex = pTempIndizes [nTempIndizes] ; 

// destroy temp cpp param => cpp: every param was 

// constructed 

uno_destructData ( pCppArgs [nlndex] , 
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ppTempParamTypeDescr [nTempIndizes] , cpp_release ) ; 
TYPELIB_DANGER__RELEASE ( 

ppTempParamTypeDescr [nTempIndizes] ) / 

} 
} 

// return type 

if (pReturnTypeDescr ) 

TYPELIB_DANGER_RELEASE ( pReturnTypeDescr ); 

} 
} 



20 

[0165] In Figure 12, read parameters operation 1201 reads the parameters from the call. Read parameters operation 
1201 transfers to convert parameters operation 1202. Convert parameters operation 1202 converts the parameters 
read to the C++ environment. A C++ call stack is built in memory. All simple types, up to eight bytes are put directly 
on the stack, and all other types are referenced by a pointer. Operation 1202 transfers to allocate memory operation 

25 1 203. Allocate memory operation 1 203 allocates memory for the out parameters returned by the call to the C++ inter- 
face, and for the return value. Allocate memory operation 1203 transfers processing to dispatch call operation 1204. 
[0166] Dispatch call operation 1204 performs a C++ virtual call on the C++ interface. In one embodiment, method 
callVirtual, an assembly function performing the specific virtual call having the right registers set (See Table 18), is 
called and passed an array that is the call stack. The call is executed in the C++ environment and the results, if any, 

30 are returned to operation 1204 that in turn transfers to exception check operation 1205. 

[0167] Exception check operation 1205 determines whether an exception was thrown in response to the call. If an 
exception was thrown, check operation 1205 transfers processing to convert exception operation 1210 and otherwise 
processing transfers to set exception operation 1220. 

[01 68] Convert exception operation 1210 converts the C++ exception to the UNO environment and sets an exception 
35 out any with the converted exception. Operation 1210 transfers to clean up operation 1211 that in turn cleans up any 
temporary parameters that were created in the call in operation 1204 and transfers to return to operation 1130. 
[0169] If an exception was not thrown in the source environment, set exception operation 1220 sets the exception 
out any to zero, and transfers to convert parameters operation 1221 . 

[0170] Convert parameters operation 1221 converts any parameters that were returned from operation 1204, e.g., 
40 out parameters and/or inout parameters, from the source environment, i.e., the C++ environment, to the destination 
environment, i.e., the UNO environment. Operation 1221 also cleans up any temporary parameters that were created 
in the call in operation 1204 and transfers to convert return value operation 1222. Operation 1222 converts any return 
value from the source environment to the destination environment so that both the return value and any returned 
parameters are written back, in this example to the UNO caller. 

45 
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TABLE 18.: AN EXAMPLE OF A METHOD 
callVirtualMethod THAT IS USED BY THE UNO PROXY TO 
DISPATCH A CALL TO THE INTERFACE IN THE C++ ENVIRONMENT 



inline static void callVirtualMethod ( void * pThis, 
sal_Int32 nVtablelndex, void * pRegisterReturn, 
typelib__TypeClass eReturnTypeClass , sal_Int32 * 
pStackLongs, sal_Int32 nStackLongs ) 
{ 

// parameter list is mixed list of * and values 
// reference parameters are pointers 

OSL_ENSHURE( pStackLongs pThis, "### null ptr!" ); 
OSL_ENSHURE( (sizeof(void *) == 4) && 

(sizeof (sal_Int32) == 4), "### unexpected size of int ! 
) ; 

asm 

{ 

mov eax, nStackLongs 

test eax, eax 

je Lcall 
// copy values 

mov ecx, eax 

shl eax, 2 // sizeof ( sal_Int 32 ) = 4 

add eax, pStackLongs // params stack space 

Lcopy: sub eax, 4 

push dword ptr [eax] 

dec ecx 

jne Lcopy 
Lcall: 
// call 

mov ecx, pThis 
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push ecx // this ptr 

mov edx, [ecx] // pvft 

mov eax, nVtablelndex 

shl eax, 2 // sizecf(void *) 

add edx, eax 

call [edx j //interface method call must be 
// register return 

mov ecx, eReturnTypeClass 

cmp ecx, typelib_TypeClass_VOID 

je Lcleanup 

mov ebx, pRegisterReturn 

// int.32 

cmp ecx, typelib_TypeClass_LONG 

]e Lint32 

cmp ecx, typelib_TypeClass_UNSIGNED_LONG 

je Lint32 

cmp ecx, typelib_TypeClass_ENUM 

je Lint32 
// int8 

cmp ecx, typelib_TypeClassJBOOLEAN 

je Lint8 

cmp ecx, typelib_TypeClass_BYTE 

je Lint8 
// intl6 

cmp ecx, typelib__TypeClass_CHAR 

je Lintl6 

cmp ecx, typelib_TypeClass__SHORT 

je Lint 16 

cmp ecx, typelib_TypeClass_UNSIGNED__SHORT 

je Lintl6 
// float 

cmp ecx, typelib_TypeClass_FLOAT 

je Lfloat 
// double 

cmp ecx, typelib_TypeClass_DOUBLE 

je Ldouble 
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// int64 

cmp ecx, typelib_TypeClass_HYPER 

je Lint64 

cmp ecx, typelib_TypeClassJJNSIGNED_HYPER 

je Lint64 

jmp Lcleanup // no simple type 
Lint8 : 

mov byte ptr [ebx], al 

jmp Lcleanup 
Lintl6: 

mov word ptr [ebx] , ax 

jmp Lcleanup 
Lf loat : 

fstp dword ptr [ebx] 

jmp Lcleanup 
Ldouble : 

fstp qword ptr [ebx] 

jmp Lcleanup 



Lint64 : 
mov 
mov 
jmp 

Lint 32 : 



dword ptr [ebx], eax 
dword ptr [ebx+4], edx 
Lcleanup 



dword ptr [ebx] , eax 
Lcleanup 



mov 
jmp 
Lcleanup : 

// cleanup stack (obsolete though because of function) 
mov eax, nStackLongs 

shl eax, 2/1 sizeof ( sal_Int 32 ) == 4 

add eax, 4 // this ptr 

add esp, eax 

} 
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[0171] In the above description of the example, various methods were described and discussed. Figure 13A to 24 
are specific examples of one embodiment of such methods. In particular, in Figs 13A and 13B, an embodiment of 
mapping an interface from the UNO environment to the C++ environment is presented. See Figure 4. 
[0172] Fig. 14 is an example of a method free and a method for revoking the proxy. Method free is called indirectly 
5 by the C++ proxy described above when the reference count goes to zero and the C++ proxy should be deleted. Fig. 
15 includes an example of a C++ proxy that includes a method acquireProxy; an example of a method releaseProxy 
that is used to revoke the C++ proxy from the C++ environment structure; and a method ccpu_cpp Interface Proxy to 
instantiate, acquire and register the C++ proxy. 

[01 73] Figs. 1 6A and 1 6B include an example of a method free that is called indirectly by the UNO proxy described 
10 above when the reference count goes to zero and the UNO proxy should be deleted; an example of a method acquire 
that is used in acquiring the UNO proxy; and an example of a method release that is used to revoke the UNO proxy. 
[0174] In Figs 17A and 17B, an embodiment of a method Mapping for mapping from the C++ environment to the 
UNO environment is presented. Figure 18 includes is a C++ implementation of the UNO proxy that includes a con- 
structor cpu_unolnterfaceProxy to instantiate, acquire and register the UNO proxy; a method for acquiring a mapping 
15 and a method for releasing a mapping. 

[0175] Figure 19 illustrates constructors for a mapping and a bridge; and a method for freeing a bridge. Figure 20 is 
an embodiment of methods for acquiring and releasing a bridge. Figure 21 includes a method cppu_ext_getMapping 
to create a mapping between two specified environments. Figure 22 is an embodiment of a method to create the static 
part of an object Id. 

20 The object id contains two parts, an object specific part and a static part. Figure 23 is an embodiment of a method to 
create a complete object Id, containing both, the object specific and the static parts. Figure 24 includes a method for 
acquiring a C++-uno environment; a method for releasing a C++-uno environment; and a method to initialize a C++- 
uno environment. 

[0176] In the following, further embodiments of the invention will be described with respect to Figs. 25 - 38. 

25 [0177] First, reference is made to Fig. 25. A first software program 251 , created with any convenient programming 
language, for example C++, and compiled with a certain compiler for C++, uses a first binary specification. This first 
binary specification depends on both, the programming language and on the compiler. The first software program 251 
may be, for example, able to present numbers in graphical form. In order to calculate the exact dimensions of the 
graphs the first software program 251 may want to employ a second software program 252 ; created with another 

30 programming language, for example Java, and compiled by using a certain compiler for Java. This second software 
program 252 uses the second binary specification for communication. 

[0178] The use of the second software program 252 by the first software program 251 requires its initialization, for 
example, by calling a loader function 255. The second software program 252 may then initialize its sub-program 252a 
for creating the stub 254. The sub-program 252a must consider the limited functionality in order to arrive at the desired 
55 stub 254, namely a module for transforming commands and responses relating to the requested limited functionality. 
Based on this limited functionality, the sub-program 252a selects the relevant mappings of the bridge 257 between the 
second binary specification and the intermediate binary specification. 

[0179] The first software program 251 may correspondingly initiate a sub-program 251a to create the proxy 253 in 
a similar way, by employing the bridge 256 between the first binary specification and the intermediate binary specifi- 
40 cation. This sub-program 251a may be informed about the limited functionality from the first software program 251 . 
However, it may also know this limited functionality from the second software program 252 by communicating via the 
communication channel 258. This channel 258 may be any suitable real or virtual connection which allows the transfer 
of data. 

[0180] After the stub 254 and proxy 253 have been created they are arranged so as to allow the communication 
45 between the first software program 251 and the second software program 252. Once this arrangement is effected the 
first software program 251 sends the command to be transformed to the proxy 253. The proxy 253 may transform this 
command from the first binary specification into the intermediate binary specification. This intermediate binary speci- 
fication corresponds, for example, to the binary UNO specification. The proxy 253 may transmit this command in the 
intermediate binary specification to the stub 254. The stub 254 may transform the command from the intermediate 
50 binary specification into the second binary specification and may transmit the command then to the second software 
program 252. 

[0181] The second software program 252 may execute the command, for example, the command to calculate the 
dimensions of a graph and may generate a response for the first software program 251 . This response may be trans- 
formed and transmitted by the stub 254 and the proxy 253 from the second software program 252 to the first software 
55 program 251 . 

[01 82] The arrows shown in Fig. 25 between the first software program 251 , the proxy 253, the stub 254. the second 
software program 252 and the loader function 255 show the possible routes of communication. The arrows between 
the proxy 253 and the bridge 256 and between the stub 254 and the bridge 257 represent the contribution of the bridges 
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256 and 257 to the creation of the proxy 253 and the stub 254, respectively. 

[0183] Fig. 26 represents an example for the initial communication of a first software program 251 and a second 
software program 252. The initial communication between the two software programs 251 , 252 is carried out, before 
the creation of the stub 254 and of the proxy 253 is initiated. Due to the different binary specifications used by the two 
5 software programs 251 , 252, namely the first and the second binary specification, this initialcommunication will regularly 
be extremely limited. It may be effected as explained exemplary in the following. 

[0184] In a first step 2600 the first software program 251 may call a loader function 255 for the second software 
program 252. The loader function 255 may be any known loader function for this second software program 252. A 
loader function for a program is a software module which "wakes up" this program so that it carries out certain functions. 
10 Herein, the loader function may be addressed in one binary specification and may wake up a program using a different 
binary specification. However, the loader function is not suited to provide any detailed communication between pro- 
grams using different binary specifications. 

[0185] The loader function 255 may be used by the first software program 251 from the beginning. This is the case, 
if the first software program 251 knows or assumes that the second software program 252 does not use the same 
15 binary specification as itself, namely the first binary specification. If this knowledge is not present in the first software 
program 251 , it may simply try to call the second software program assuming that it will understand the first binary 
specification. In this case, the first software program 251 may only employ the loader function 255 if the direct com- 
munication with the second software program 252 fails and a corresponding message is returned to the first software 
program 251 . 

20 [0186] In the calling step 2600 the first software program 251 informs the loader function 255 about the limited func- 
tionality requested from the second software program 252. Therefore, the loader function 255 must be suited to receive 
and carry this information. In order to provide this information to the loader function 255 the first software program 251 
may hand over to the loader function 255 the command to be carried out by the second software program 252, so that 
the second software program 252 may, on receipt of the call of the loader function 255 decide itself which functionality 

25 is needed, orthe first software program 251 may providethe loader function 255 directly with the description of a limited 
functionality of the second software program 252 which will be required by the first software program 251 . 
[0187] In step 2601 the loader function 255 contacts and initializes a reception function of the second software pro- 
gram 252 to be able to transmit in the next step 2602 its information about the limited functionality required from the 
second software program 252. In the next step 2603 the second software program 252 analyses the information re- 

30 ceived from the loader function 255 regarding the required limited functionality. After the analysis of the limited func- 
tionality required the second software program 252 initializes the creation of a stub 254. 

[0188] Fig. 27 shows the creation of a stub 254. The stub 254 has the task to transform commands sent by first 
software program 251 to the second software program 252 from the intermediate binary specification into the second 
binary specification used by the second software program 252 and to transform responses sent by the second software 
55 program 252 back to the first software program 251 from the second binary specification into the intermediate binary 
specification. Furthermore, the stub 254 may be assigned the taskto transmit the transformed commands or responses 
to the recipients, the second software program 252 or the proxy 253, respectively. 

[0189] In step 2700 the second software program 252 may initialize a sub-program 252a for creating the stub 254. 
This sub-program 252a may be an integral part of the second software program 252 or it may be as well a separate 
40 independent software module which can be used by this and potentially any other second software program 252. 
Accordingly, the sub-program 252a may be stored on the computer system or storage device on which the second 
software program 252 is stored. However, the sub-program 252a may also be stored on another computer system or 
storage device to which the second software program 252 has access. 

[01 90] In step 2701 the sub-program 252a receives from the second software program 252 a description of the limited 
45 functionality required from the second software program 252. Then, in step 2702 the bridge 257 between the second 
binary specification used by the second software program 252 and the intermediate binary specification is contacted. 
This bridge 257 provides a mapping of at least all basic commands between the mentioned two binary specifications. 
It may be stored at any place accessible for the sub-program 252a. In many cases there may exist a library with bridges 
for a number of second binary specifications, assuming that the intermediate binary specification used would be the 
50 same for all intended operations. 

[0191] From the selected bridge 257 the sub-program 252a chooses in step 2703 the mappings necessary to use 
the required limited functionality of the second software program 252. This means all transformations, but not more 
than these, must be selected which are required to transform commands and responses which could arise when using 
the relevant functionality. Finally, in step 2704 the sub-program 252a creates the stub 254 based on the chosen map- 
55 pings. 

[0192] Fig. 28 represents in the form of a flow chart the creation of the proxy 253. The proxy 253 has the task to 
transform commands and responses between the first binary specification and the intermediate binary specification. 
It is insofar similar to the stub 254 which has, as it was described above, the task to render these transformations 
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between the second binary specification and the intermediate binary specification. 

[0193] In step 2800 the first software program 251 may initialize a sub-program 251 a for creating the proxy 253. This 
sub-program may be an integral part of the first software program 251 , but may as well be separate and independent 
from it. The sub-program 251 a may be accessible for a larger number of first software programs 251 . In step 2801 the 

5 sub-program 251 a receives from the first software program 251 information regarding the limited functionality required 
from the second software program 252. This information may be provided by passing on the actual command the first 
software program 251 plans to send to the second software program 252, so that the sub-program 251a may derive 
from this command the information about the limited functionality, or the first software program 251 may provide the 
sub-program 251 a with a description of the limited functionality. 

10 [0194] In an alternative embodiment the description of the limitedfunctionality may be received from the sub-program 
252a for creating the stub 254. The sub-program 252a has the required description, because it has to create the stub 
254 according to the same description. The description may be exchanged between the sub-program 252a and the 
sub-program 251 a by any suitable means of communication. 

[0195] In yet an alternative embodiment the description of the limited functionality of the second software program 
15 252 may be derived directly by mapping the stub 254 into the first binary specification, in order to create a proxy. This 
is possible, because the stub 254 reflects the required limited functionality in listings between the second binary spec- 
ification and the intermediate binary specification which are necessary for the transformation of commands and re- 
sponses. Therefore, the intermediate binary specification side of the listings of the stub 254 may be taken as the starting 
point for the creation of the proxy 253, which is completed by adding the corresponding parts of the listing in the first 
20 binary specification, as will be explained below. 

[0196] In step 2802 the sub-program 251a contacts the bridge 256, which provides a mapping of basic commands 
of the first binary specification and the intermediate binary specification, and builds, in step 2803, the desired proxy 253. 
[01 97] The proxy 253 and stub 254 are then arranged to allow the desired communication between the first software 
program 251 and the second software program 252, as it will be described in the following along the flow chart of Fig. 
25 29. The arrangement of proxy 253 and stub 254 requires that the path of exchanging transformed commands and 
responses between the proxy 253 and the stub 254 is defined. 

[0198] Therefore, in step 2900 the second software program 252 informs the first software program 251 about the 
address information necessary to contact the stub 254 via the communication line 258. The communication line 258 
may consist of a simple data line for transmitting binary address information which can be understood from the first 
30 software program 251 without being able to use the second binary specification in which the second software program 
252 communicates. 

[0199] The first software program 251 provides, in step 2901, the sub-program 251a with this received address 
information, which, in step 2902, is passed on to the proxy 253. The proxy 253 then contacts, for the first time in step 
2903, the stub 254, the address of which is now known. In step 2903 the proxy 253 will also transmit its own address 

35 information to the stub 254, thereby allowing the stub 254 to contact the proxy 253. 

[0200] Herewith, the proxy 253 and the stub 254 are arranged for communication, that means they can send and 
receive commands and responses to commands. This arranging step is also referred to as binding. 
[0201 ] Fig. 30 shows a computer system 300 wh ich may be used in the scope of the present invention. The computer 
system 300 comprises an i-/o-interface 301 , a central processing unit (CPU) 302 and memory 303. It is connected to 

40 an external memory 304 on which mass data may be stored as well as software programs. Furthermore, the computer 
system 300 is connected via the i-/o- interface 301 to an output device 305, for example, a screen, and to an input 
device 306, for example, a keyboard. 

[0202] The inventive method may be applied in the shown standard computer system. The first software program 
251 and the second software program 252 may be stored in the internal memory 303 of the computer system 300, as 
45 well as on its external memory 304. It is also possible that one of the programs is stored on the internal memory 303 
and the other is stored on the external memory 304. The proxy 253 and the stub 254 may be created by means of the 
CPU 302. 

[0203] The method according to the present invention may also be implemented and used on more than one computer 
system, for example, in a network or in a client-server system, as it is shown exemplary in Fig. 31 . 

50 [0204] Fig. 31 shows a client 310 which is connected to a server 311 . This connection may be a data line 312, 
including any kind of permanent or temporary network, like, for example, the internet. It is understood that, instead of 
only one client, there may be a large number of clients connected to the server. In the scope of the present invention 
the first software program 251 may, for example, be stored on client 310, while the second software program 252 may 
be stored on server 311. The exchange of commands and responses may be effected via data line 31 2. For example, 

55 the bridges 256 and 257, as well as any other potentially needed bridges may be stored in one or more libraries on 
the server 31 1 . The sub-programs 251a and 252a may also be stored on the server 311 . In case the sub-program 251a 
is needed the client 310 may request from the server 311 its transmission via data channel 31 2. 
[0205] It is understood that the present invention may also be implemented in a variety of embodiments. In the 
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following one embodiment of the present invention is described in more detail along Figures 32 to 35 and Tables 1 and 2. 
Creation of stub and proxy: 

5 [0206] In response to a call of a first software program a proxy and a stub will be created in the so-called proxy 
factory and the stub factory, respectively. In order to create a proxy and a stub three tasks have to be carried out. First, 
the first software program using the first binary specification has to be enabled to communicate with to the second 
software program using the second binary specification. Second, the stub factory has to create a uno_interface imple- 
mentation considering the second binary specification based on the limited functionality which delivers all calls directed 

10 to the second software program to this second software program. This uno_interface is program code which is defined 
forthe limited functionality. Forthe generation of the uno_interface implementation the stub factory employs information 
in the form of a type description. This uno_interface implementation is also referred to as the stub. Third, the proxy 
factory has to create a uno interface implementation for the first binary specification. The proxy factory generates its 
uno interface implementation based on the information of the type description. This uno_interface implementation is 

*5 referred to as the proxy. 

[0207] The knowledge of the type description is necessary to create the stub and the proxy, as described. This type 
description is the full description of the limited functionality, also called interface. It contains the information about the 
required limited functionality of the second software program which shall be used by the first software program. The 
type description may refer to different types shown in Table 1 . 

20 



Table 1 : 





Type 


UNO 


C++ 


Java 




Byte 


Signed 8 Bit 


Signed 8 Bit 


Signed 8 Bit 


25 


Short 


Signed 16 Bit 


Signed 16 Bit 


Signed 16 Bit 




Ushort 


Unsigned 16 Bit 


Unsigned 16 Bit 


Signed 16 Bit 




Long 


Signed 32 Bit 


Signed 32 Bit 


Signed 32 Bit 


30 


Ulong 


Unsigned 32 Bit 


Unsigned 32 Bit 


Signed 32 Bit 




n y pel 


^innfiH RA Rit 

OiyilcU OH DIL 


^inn^H RA Rit 

OiyMfcrU OH- OIL 


^innpkH RA Rit 

OILJMcU OH- OIL 




U hyper 


Unsigned 64 Bit 


Unsigned 64 Bit 


Signed 64 Bit 


35 


Float 


Processor dependent: Intel, 
Sparc = IEEE float 


Processor dependent: Intel, 
Sparc = IEEE float 


IEEE float 




Double 


Processor dependent: Intel, 
Sparc = IEEE double 


processor dependent. Intel, 
Sparc = IEEE double 


IEEE double 


40 


Enum 


The size of an machine word. 
Normally this is the size of an 
integer, 


The size of an machine word 
Normally this is the size of an 
integer, 


All enum values of one enum 
declaration are static object of a 
class. Each object contains a 32 
bit value which represents the 
enumeration value. 


45 


Boolean 


1 Byte 


1 Byte. 


Boolean 


Char 


1 6 Bit on WNT, W95, W98, Os2. 
32 Bit on Unix 


1 6 Bit on WNT, W95, W98, Os2. 
32 Bit on Unix 


Unsigned 16 bit (char) 


50 


String 


A pointer to a structure which 
have the following members: 
long refCount; 


A pointer to a structure which 
have the following members: 
long refCount; 


"java.lang. String" 




Type 


UNO 


C++ 


Java 


55 




long length, wchar_t buffer[ .]; 
The string in buffer is 0 
terminated. This is the 
rtl_wString structure in the rtl- 
library 


long length; wchar_t buffer[...]; 
The string in buffer is 0 
terminated. This is the 
rtl_wString structure in the rtl- 
library 
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Table 1 : (continued) 





Type 


UNO 


C++ 


Java 


5 


Structure 


The structure contains the 
members in the order of the 
declaration. The Structure 
memory layout is described at 
the beoinnino of this chaoter 


The structure contains the 
members in the order of the 
declaration. The memory layout 
is described at the beginning of 
this chapter. 


A class which is derived from 
java.l an g. Object" and contains 
the java. Ian g. Object and 
contains members in the 
soecified order 


10 
15 


Union 


The size is 4 + size of the 
largesttype In front of the union 
members are a long value 
(nSelect) which describes the 
position of the valid member (0 
is of the first). 


Thesize is 4 + size of the largest 
type. In front of the union 
members are a long value 
(nSelect) which describe the 
position the valid member (0 is 
the first). 


Not specified yet 


20 


Sequence 


A pointer to a structure which 
has the following members, 
void* pElements; long 
nElements; long nRefCount; 
The pElements are a memory 
area that contains nElements 
elements. 


A pointer to a structure which 
has the following members: 
void * pElements, long 
nElements; long nRefCount; 
The pElements are a memory 
area that contains nElements 
elements. 


It is a normal Java array. 


25 


Exception 


Looks like a structure 


Looks like a structure 


A class which is derived from 
iava lann Fxrpntion" and 

J C4 V CI 1 CI 1 1 \U . 1 — Av^U Llwl 1 CI 1 1 \A 

contains the members in the 
specified order. 


30 


interface 


The interface is a pointer to a 
function table, which contains 3 
functions. 


It is a pointer to a C++-Class 
which implements first the 
virtual methods query Interface, 
acquire and release. 


It is a normal Java interface. 


35 


Any 


This is a structure that contains 
a pointer to a type description. 
The second member is a 
pointer to the value stored in 
the any. 


This is a structure that contains 
a pointer to a type description 
Thesecond member is a pointer 
to the value stored in the any. 


A class which is derived from 
"java. lang. Object". The 
members are a class, which 
describe the type of the value, 
second member which is the 
value of the any. 




Void 


No memory representation 


No memory representation 


No memory representation 



40 



[0208] Many of these types are self-explaining and known in the art. Nevertheless, the most relevant types of the 
type description will be explained in more detail below. 

[0209] "Interfaces": All interfaces employed in connection with the present embodiment are derived from a Super- 
Interface. Each interface contains at least three methods. The two methods "acquire" and "release" are necessary to 
45 control the lifetime of the interface. The third method "query Interface" is used to navigate between different Interfaces. 
A Xlnterface includes only these three methods. All other interfaces are derived from this Xlnterface. The methods and 
functionalities requested by the first software program will be part of the interface. 

[0210] In Java, for example, interfaces are mapped to Java interfaces which could be normally implemented. The 
methods acquire and release are not mapped to the Java program since this methods do not exist in Java. The lifetime 
50 of the proxy, the stub and the relevant information in the second program will be controlled by a garbage collector. The 
programming language Java delivers basic types by value and non-basic types by reference. All calls are specified by 
value except interfaces. So in Java all non-basic types returned or delivered through out parameters are by value, 
which means that the implementation must copy it before return or deliver. 

[0211] In C++, for example, interfaces are mapped to pure virtual classes. In order to automatically control the lifetime 
55 of interfaces a template called "Reference" will be used. All return, parameter and member types are "References" (e. 
g.: Reference< Xlnterface >). The "Reference" acquires the interface when it is constructed and releases the interface 
when it is destructed. 

[0212] "Structure": A structure is a collection of elements. The type of each element is fixed and it cannot be changed. 
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The number of elements is fixed. 

[0213] "Exceptions": An exception is a program control construct beside the normal control flow. One major feature 
of exceptions is, that it is simpler to implement the error handling. Exceptions are similar to structures since they are 
also a collection of elements and each type of each element is fixed and cannot be changed and the number of elements 
5 is also fixed. An additional feature of exceptions is that they can be thrown by a method. All exceptions which can be 
thrown by a method must be declared at the method, except for the called "RuntimeException" which always can occur. 
All exceptions must be derived from "Exception". If an exception is declared at a method it is allowed to throw all derived 
exceptions. The caller of a method must respond to this behavior. 

[0214] In Java, for example, all exceptions are derived from the "java.lang. Exception". The exceptions are declared 
10 at the methods. 

[0215] In C++, for example, the exceptions are generated as structures. An exception is thrown as instance (e.g.: 
throw RuntimeException()). At the other side the exception should be caught as reference (,..catch(RuntimeException 
&){...}). 

[0216] "Union": A union contains one element. The declaration of a union specifies the possible types. 

15 [021 7] "Array": An array contains any number of elements. The type of the elements is fixed and cannot be changed. 
[0218] "Any": An any contains one element. All types of elements are possible. An any contains a reference to the 
value and the type description of the type. With the type description the bridge can transform the value, if necessary. 
[0219] In Java the any is, for example, represented by the class "Any", which contains a class as type description 
and a "java.lang. Object", which is the value. The basic types are wrapped to their proper classes. For example, a 

20 boolean value is an object of the class "java.lang. Boolean", which contains the value. 

[0220] In C++ the any is represented through the class "Any". Each type generated by a C++ codemaker implements 
an function "getCppuType". This function is used to implement the template access operators "«=" and "»=". These 
operators insert and extract the value of the any. 

[0221] "Sequence": A sequence is a generic data type. It contains the number of elements and the elements. In Java 

25 the specification of an array fulfills this specification. This is not true for C++. The array in C++ does not contain the 
number of elements. It is not possible to return a C++-array, e.g. CharQ getName() is not possible. It is difficult to 
manage the lifetime between the called and the caller, if only a pointer is returned. Therefore, in C++ a sequence is a 
template with the name "Sequence". The implementation contains a pointer to a structure which contains a pointer to 
the elements, the number of elements and the reference count. So it holds the binary specification. It is cheap to copy 

30 this sequence, because only the reference count is incremented. 

[0222] The type description may exist or it may be runtime created. Each existing type is stored in a type repository 
along with the corresponding type description. The types of the type description are accessible through the full name 
of each type in the type repository. For example, the full name of the type "Xinterface" may be"com.sun.star.Xinterface". 
[0223] In a type repository the types needed for any type description are stored in any appropriate way. If the API 

55 (application program interface) of the type repository is c-style, it is directly, that means via a binary representation, 
accessible from many binary specifications and it is quickly transferable. Since the type description of each element 
may be used during the generic marshaling of a call, the access performance of the type repository API is critical. 
Therefore, it is useful to use c-style structures, which describe each type. In addition, there may be interfaces declared 
which specify the access to the type repository. The module of this interface is "com.sun.star.typelib". 

40 [0224] All functions or type declarations have the prefix "typelib_". All elements are reference counted. All elements 
start with the structure "typelib_TypeDescription". It is possible to cast all descriptions to this type. The function typelib 
typedescription newlnterface will be used to create an interface description. The descriptions of structures, unions and 
sequences are created with the function typelib_typedescription_new. The description of the base type is initially part 
of the type repository. The function to get a type description is typelib_typedescription_getByName. 

45 [0225] The Java API to the type repository is different for two reasons. First, Java cannot access the binary repre- 
sentation of the type descriptions directly. 

[0226] Second, the Java runtime system provides an API (core reflection) similar to the type repository API. Unfor- 
tunately, the features "unsigned", "oneway" and "out parameters" are missing in this API. For this reason, additional 
information is written into the classes. 
50 [0227] The representation of the types depends on the hardware, the language and the operating system. The base 
type is swapped, for example, if the processor has little or big endian format. The size of the types may vary depending 
on the processor bus size. The alignment is processor and bus dependent. The alignment of the data structure is 
defined through the following algorithm: 

Structure members are stored sequentially in the order in which they are declared. Every data object has an alignment- 
55 requirement. For structures, the requirement is the largest of its members. Every object is allocated an offset so that 
offset % alignment-requirement == 0 

[0228] If it is possible that the maximum alignment can be restricted (Microsoft C/C++ compiler, IBM C/C++ compiler) 
than the size maximum alignment is set to eight. Under this condition the alignment is set to min( n, sizeof (item ) ). 



69 



EP1 122 644 A1 



The size is round up to the largest integral base type. 

[0229] For the Microsoft and IBM C/C++ compiler the alignment of structure is set to eight using the "#pragma" 
statement. Table 1 shows the binary UNO, C++ and the Java types. 

[0230] In order to address the proxy factory to generate the proxy the first binary specification has to be denominated. 

5 This will be a string, because it is extensible and the risk of double names is low. Then a tool for selecting the desired 
bridge is called. The first parameter for this tool is the "first binary specification" and the second parameter is the 
intermediate binary specification "UNO". Then a function is called for selecting the desired mapping of the bridge. The 
name of the function is, in this example, "getMapping Factory". A call to create a proxy in "objective c" will be "getMap- 
pingFactory("objective_c", "uno")". The implementation of the function will search a shared library named 

10 "objective_cuno" to find the right library that contains the proxy factory. In Java the tool may search for a class of name 
"objective_cuno". 

[0231] In order to create a stub merely the parameters of the function have to be changed, in our example to "get- 
MappingFactory("uno", "objective_c")". A stub implements the uno_interface. In the dispatch function the stub must 
call the right method of the original object. This is simpler in a programming language like Java, which has a "core 
15 reflection API", than in a programming language like C++, which has no binary standard and no API to call virtual 
methods. 

[0232] In creating a proxy the proxy factory must generate method code to implement each method specified in the 
interface to be created. The only information to do this is a type description of the interface. For example: In Java (1.1) 
a binary class file (*. class) must be generated and loaded with the class loader. In the absence of a loader which can 
20 directly load binary classes a loader has to be provided. In C++ virtual method tables must be generated which delegate 
each call to the uno_interface. In the absence of a binary C++ specification individual compilers (version, switch, ...) 
may have to be explored in order to implement this. 

[0233] The proxy and the stub factory employ bridges for the generation of the proxy and the stub, respectively. A 
bridge implements infrastructure to exchange interfaces between two environments and is bidirectional. 

25 [0234] An environment contains all objects which suffices the same specification and lies in the same process address 
space. The environment is specific for a programming language and for a compiler. For example, an object resides in 
the "msci" environment, if it is implemented in C++ and compiled with the Microsoft Visual C++ compiler. It may also 
be session specific for some reason, e.g. when running multiple Java virtual machines in one process. In the latter 
case these virtual machines have to be distinguished. However, this case is not a common case. 

30 [0235] Regularly, the environment is the area in which the same binary specification is employed. Therefore, the first 
software program and the second software program belong to different environments. 

[0236] Each bridge is implemented in a separate shared library. The name of the library is a connection of two 
environment names with an underscore ('_') between the names. Each bridge library exports two functions called 
"uno_ext_getMapping" and "uno_initEnvironment". The first function is called to get the mappings. 

35 [0237] In order to get a mapping uno_getMapping () has to be called. There is also a C++ class called cppu Bridge 
which can be used with the source and destination environment names. The uno_ext_getMapping () call then receives 
its source and destination environments. The bridge library cannot be unloaded while any code of it is still needed. So 
both mappings and any wrapped interface (proxy) that is exported needs to modify a shared library wide reference 
count. If the shared library can be unloaded the reference count goes to zero. 

40 [0238] The intention of an environment structure is to provide common functions like acquirelnterfaceQ and to know 
all proxy interfaces and their origins. This is specifically important because of the object identity of an interface. The 
proxy, the stub and the second program are defined to provide the same instance of the Xlnterface any time it is queried 
for it. This is important to test, if two interfaces belong to the same object (e.g. testing the source of an incoming event). 
[0239] When interfaces are mapped around some environments in space, they must provide the same Xlnterface 

45 in each environment (e.g. in C++, equal Xlnterface pointers). 

[0240] It is not recommended to only keep an eye on this object identity issue. It is well recommended to reuse any 
interface, i.e. rejecting the production of proxy interfaces as often as possible, because each constructed proxy interface 
leads to another indirection when called, and there will of course be many interfaces. 

[0241] So an environment knows each wrapped interface (proxy) running in it and the origin of each of these inter- 
50 faces. Table 2 shows the representation of an environment. 
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Table 2: 

struct uno_Environment 
{ 

/ * * 

* a name for this environment 

V 

rtl_String * pName; 
/** 

* a free context pointer, that can be used for specific classes 
envi ronments, 

* e.g. a jvm pointer 
*/ 

void * pContext; 
/** 

* Acquires this environment. 
*<BR> 

* laparam pAccess this access interface 
*/ 

void (SAL_CALL * acquire) { uno_Environment * pEnv ) ; 
/** 

* Releases this environment; 

* last release of environment will revoke the environment from runtime, 
*<BR> 

* @param pAccess this access interface 

*/ 

void ( SAL__CALL * release) ( uno_Environment * pEnv ); 
/** 

* Tests if two environments are equal. 

*<BR> 

* @param pEnvl one environment 

* @param pEnv2 another environment 
*/ 

sal__Bool (SAL_CALL * equals) ( const uno_Environment * pEnvl , 

const uno^Environment * pEnv2 ) ; 

/** 

* You register internal and external interfaces via this method. 

* Internal interfaces are proxies that are used in an environment. 

* External interfaces are interfaces that are exported to another 

* environment, thus providing an object identifier for this task. 

* This can be called an external reference. 

* Interfaces are held weakly at an environment; they demand a final 

* revokelnter face () call for each interface that has been registered. 
*<BR> 
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* Gparam pEnv this environment 

* @param pplnterface inout parameter for the registered interface 

* G-param ppOId inout parameter for the corresponding object id 

* (gparam pTypeDescr type description of interface 
5 * (jjparam acquire function to acquire an interface; 

* this function provides a boolean return 

* value to signal if the acquisition was successful (necessary for 

* proxy interfaces) 
*/ 

void (SAL_CALL * registerlr.ter f ace) ( uno_Environment * pEnv, 

void ** pplnterface, 

10 rtl_String ** ppOId, 



pTypeDescr, 



typelrb_interf aceTypeDescription * 
unoregAcquireFunc acquire ) ; 
You have to revoke ANY interface that has been registered via this 



method . 
15 *<BR> 

* (Sparam pEnv this environment 

* (^param poid object id of interface to be revoked 

* Gparam pTypeDescr type description of interface to be revoked 
*/ 

void ( SAL CALL * revokelnterface) { uno_Environment * pEnv, 

rtl_String * pOId, 

20 Lypelib Interf aceTypeDescription * pTypeDescr ) ; 

I -k * 

* Retrieves an interface identified by its object id and type from 

* this environment. 
*<BR> 

* Gparam pEnv this environment 

25 * Gparam pplnterface inout parameter for the registered interface; 

* (0) if none was found 

* Qparam pOId object id of interface to be retrieved 

* @param pTypeDescr type description of interface to be retrieved 
V 

void { SAL_CALL * getRegistercdlnter f ace ) ( uno_Environment * pEnv, 

void ** pplnterface, 
30 rtl_String * pOId, 

typelib_Interf aceTypeDescription * 

pTypeDescr ) ; 

/** 

* Retrieves the object identifier for a registered interface from 

* this environment. 
35 *<BR> 

* Qparam pEnv this environment 

* Qparam ppOId inout parameter for object id of interface; (0) if none was 

found 

* Qpararn plnterface a registered interface 

* Qparam pTypeDescr type description of interface 
*/ 

40 void (SAL_CALL * getRegisteredObj ectldentif ier) ( uno_Environment * pEnv, 

rtl_String ** ppOId, 
void * plnterface, 

typelib__Interf aceTypeDescription * 

pTypeDescr ) ; 

f * * 

45 * Disposing callback function pointer that can be set to get signalled 



before 



50 
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* the environment is destroyed. 
*<BR> 

* Qparam pEnv environment that is being disposed 
*/ 

void (SAL_CALL * environment Disposing) ( uno_Environment * pEnv ) ; 
/** 

* Computes an object identifier for the given interface; is called by 

* the environment implementation. 

* <BR> 

* @param pEnv corresponding environment 

* Qparam ppOId out param: computed id 

* Cparam plnterface an interface 
*/ 
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void < SAL_CALL * computeObjectldentif ier ) ( unojnvironment * pEnv, 

rtl_String ** ppOId, void * plnterface ); 

5 / + * 

* Function to acquire an interface. 
*<BR> 

* @param pEnv corresponding environment 

* @param plnterface an interface 

*/ 

void { SAL_CALL * acquirelnter f ace ) ( uno_Environment * pEnv, void 

10 plnterface ) ; 

/ * * 

* Function to release an interface. 

A <BR> 

* @ pa ram pEnv corresponding environment 

* (aparam plnterface an interface 

*/ 

15 void { SAL_CALL * releaselnter f ace ) { unojnvironment * pEnv, void 

plnterface ) ; 
} ; 



20 [0242] Environments, as defined above, consist of several fields. The first fields are used for identifying the environ- 
ment, for specifying the hardware, the process, and maybe a session specific ID. There is also a context pointer which 
can be used for specific classes of environments, e.g. when it is known that there is a Java environment the virtual 
machine pointer can be stored there. 

[0243] In order to use environments, these environments regularly have to be registered. An existing environment 

25 may be obtained by calling uno_getEnvironment(). A new environment can be created by either implementing it directly 
or by using a simple default implementation, which is frequently also sufficient, by calling, in the given example, 
uno_createDefaultEnvironment() with the environment's name and its acquire and release function for interfaces. 
[0244] In order to improve the performance the bridges should use the shortest way between two environments. 
Especially, if there are programs instantiated in the identical environment, the communication between them should 

30 be direct and not over a proxy and a stub. 

[0245] Mapping is the direct way to publish an interface in another environment. That means an interface is mapped 
from a source environment to a target environment so that methods may be invoked on a mapped interface in the 
target environment which are delegated to the originating interface in the source environment. A mapped interface 
may also be called a proxy or a stub. Mapping an interface from an environment A to an environment B requires that 

55 several steps are performed: First, the origin of the interface from environment A has to be retrieved (call getlnterfa- 
ceOrigin() on environment A). For this purpose, the environment A looks into its proxy interfaces table to check if there 
is such an interface already known (pointer and type). If the answer is no, then this interface must originally come from 
environment A, or else it must originate from any other environment and its origin must be known, since each proxy 
interface must have been registered with its origin. Second, an existing proxy interface has to be looked for in envi- 

40 ronment B with the same origin and type (call getlnterface() on environment B). If a proxy interface of that origin and 
type is already in use in environment B, then this interface is acquired, or else a new proxy has to be constructed 
wrapping the sou rce interface from environment A. The fresh proxy interface is then to be registered via registerl nterface 
() on its first acquire() and revoked via revokelnterface() on its last release() from its environment. This second step 
has to be synchronized with other threads in order to get access to mapping tables of an environment by getting an 

45 access interface (lockAccess()) from the environment. Then an unlockAccess() function has to be called. 

Function of stub and proxy: 

[0246] The stub is encapsulated in an object which delivers and transforms the binary specification adapted calls to 
50 the stub. This object is the proxy of a stub in the first binary specification. This proxy which calls and attributes access 
will be similar with the binary specification from which the call was made. The calling to the stub is shown in Fig. 32. 
[0247] First in step 321 a type save call (e.g. acquire, query I nterface, ...) is made at the proxy 253. This type save 
call will be transformed by the proxy 253 to a corresponding call in step 322 and dispatched to the stub 254 in step 
323. After that, the return value of this call is transformed in step 324 to the type expected by the binary specification. 
55 [0248] The proxy is binary specification specific. So it is possible to put this object seamless into the binary specifi- 
cation. 

[0249] A stub object is also created which implements an uno_interface and transforms and delegates the calls to 
the second program implemented in a specific programming language (e.g. C++, Java,...). Fig. 33 describes a call 
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through a stub 254 to the second program 252. 

[0250] In a first step 331 the dispatch function is called. If proxy and stub are running in the same process, the 
dispatch function of the stub is directly called by the proxy. In a distributed environment this is not possible. In this case 
the abstract virtual channel has to provide this functionality. On the proxy side the proxy will accept the request and 

5 transmit it to the stub side. On the stub side the stub has to call the dispatch function. 

[0251] The stub 254 detects the interface and the method which should be called at the second program 252. Then 
in step 332 the call was transformed into a specific binary specification by the stub 254 and the second program 252 
was called in step 333. After that, the return value was re-transformed to the other binary specification in step 334. 
[0252] The stub makes all transformations to the binary specification in which the second program is implemented. 

10 This is in this example the second binary specification. This makes it possible to implement the second program in the 
second binary specification. For example: In C++ exceptions, multiple inheritance and derivation can be used. In ad- 
dition to the binary specification there are the type descriptions which must be mapped in the binary specification of 
the second program. 

[0253] In order to enable to call from one binary specification or object model to another the stub and the proxy have 
15 to undergo a binding process. The proxy allows to call from one binary specification to the uno_interface, while the 
stub allows to call through the uno_interface to the second program. The binding of the stub and the proxy is initiated 
by the first software program 251 and is shown in Fig. 34. In a first step 341 the generation of a stub with the binary 
UNO specification in the stub factory 342 is shown. In a second step 343 a proxy is created based on the generated 
stub in the proxy factory 344. 

20 [0254] Each call to the proxy is delivered to the stub. The stub prepares the call and calls the second program in the 
corresponding binary specification. Fig. 35 shows exemplary the call from a first software program 251 in a programming 
language like "objective c" to a second software program 252 which may be implemented in the programming language 
C++. 

[0255] The first software program 251 uses the programming language "objective c". The proxy 253 makes the 

25 interface available to the first software program 251 in the first binary specification. This means the first software 
program 251 uses the first binary specification to manipulate the second software program 252. For example, this may 
be effected by the call "char* pOldText = [ myObject changeText: "test"]" in step 351 . The proxy 253 transforms the 
parameter of type string to the binary specification in step 352. Then, the proxy 253 dispatches in step 353 the call to 
the stub 254. The necessary information, including a method type description, parameters, an address for the return 

30 value and an address for the exception, if any occurs, is delivered to the stub 254. The stub 254 transforms in step 
354 the string from the binary UNO specification to a second binary specification string. The stub 254 calls the right 
method at the second software program 252 in step 355, in our example "pComponent->changeText("test")". The stub 
254 must catch all kind of exceptions thrown by the second software program 252. If the method returns normally, the 
string is transformed in the step 356 to the binary UNO specification and stored at the place given through the dispatch 

55 call. If an exception is thrown, the exception is transformed and stored at the address given through the dispatch call. 
After the dispatch call returns the proxy 253 transforms in step 357 the string to a first binary specification string and 
returns from the "changeText" call. If the call terminates by an exception, the exception is returned to the first software 
program 251 . It is up to the first binary specification in which manner the exception occurs (the "objective c" language 
does not support exception handling). 

40 [0256] Fig. 36 shows the advantage of the binary UNO specification as an intermediate binary specification as it was 
described above. In a first step 361 the first software program 251 , for example written in the programming language 
C++, transmits one command in a first binary specification, in this example the command "setText("a test")", to the 
proxy 253. Regularly, the first software program will transmit more than one command, for example, also the acquire, 
the release and the querylnterface command as described above. This command will be transformed by the proxy 253 

45 in the next step 362 from the first binary specification into the binary UNO specification. The command in the binary 
UNO specification contains the following information: the parameter "a test", the return address, an address for the 
exceptions, and the type description of the command "setText". The type description of this command will include, in 
this example, the name of the command (setText), the type of the parameter and the return type. This transformed 
command will be transmitted to the stub 254 in the step 363. Then, the stub 254 transforms in step 364 the command 

50 from the binary UNO specification into the second binary specification , employed by the second software program 252 
which was written, for example, in the programming language Java. The stub 254 employs for this transforming step 
only one dispatch mechanism. This is a mechanism which will be employed for each command transmitted by the 
proxy 253, since it is able to dispatch the name of the command and the other relevant information to the second 
software program 252. In the final step 365 the second software program 252 executes the command "setText". The 

55 response to this command will be transmitted and transformed in a corresponding way. 

[0257] Fig. 37 shows a scenario where between the proxy 253 and the stub 254 an interceptor 370 is inserted. This 
means, that the stub 254 and the interceptor 370 are created in a first step, while in a second step the stub 253 is 
created based on information about the stub 254 and the interceptor 370. Therefore, the proxy 253 will communicate 
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only with the interceptor 370 and not with the stub 254. 

[0258] Such an interceptor may be able to carry out, for example, an accounting function or a security check function. 
If, for example, the first software program 251 wants to use a functionality of the second software program 252, the 
interceptor may be able to discover if the user of the first software program is authorized to use this function and to 

5 debit the account of the user, if the user has to pay for this functionality. Such an interceptor may also be used, for 
example, to help debugging the communication between a first software program 251 and a second software program 
252. In such a case the interceptor may provide an alarm function which will be initiated, if a predefined functionality 
is called. If the functions requested from the second software program 252 may be grouped as one transaction, it may 
also be possible that an interceptor cancels all already executed functions of this group, if one function fails. Such an 

10 interceptor has the advantage that only one interceptor may be employed for every function or method of an interface 
and for all binary specifications of software programs which communicate via the intermediate binary specification 
used by the stub 254 and the proxy 253. 

[0259] Fig. 38 shows a flow chart representing the use of an interceptor as checking and accounting function for a 
fax service. In this example, a user of a first software program using a first binary specification wants to use the fax 
15 service of a second software program using a second binary language. This fax service may distinguish between two 
kinds of users. A standard user may have to pay for each fax and a premium user may have to pay a monthly standard 
fee. 

[0260] In order to enable the communication between the two software programs a stub and a proxy will be created 
and combined and arranged together with a specific interceptor in a way shown in Fig. 37. Then, the following steps 
20 may be carried out in using the invention. 

[0261 ] In step 3800 the first software program sends a command including the desired fax number, the corresponding 
fax file and the identity of the user to the proxy. The proxy transforms this command into the intermediate binary spec- 
ification and forwards it to the interceptor in step 3801. The interceptor checks in step 3802 whether the user is a 
standard user. 

25 [0262] If the answer is "Yes", that means the user is a standard user, the interceptor may deteremine in step 3803 
whether the user has enough credit. If the answertothis question is "No", the userwill be informed about his insufficient 
credit status and about the fact that the fax was yet not sent in step 3804. If the answer is "Yes", that means that the 
user has enough credit, the interceptor will initiate, in this example, the debiting of the user's account in step 3805 and 
forward the received command to the stub in step 3806. 

30 [0263] If the answer in step 3802 is "No", that means the user is a premium user, the interceptor will forward the 
command received from the proxy directly to the stub in step 3806. The stub will transform this command from the 
intermediate binary specification into the second binary specification and forward this command to the second software 
program in step 3807. Then the fax may be sent. 

[0264] It will be understood that the present invention is not limited to the examples given and explained in detail. 

35 

Claims 

1 . A method for enabling a first software program using a first binary specification in a first execution environment to 
40 employ a limited functionality of a second software program using a second binary specification in a second exe- 
cution environment, the method comprising: 

creating a bridge in said first execution environment; and 

45 creating, in said first execution environment using said bridge, a proxy wrapping an interface to said limited 

functionality of said second software program in said second execution environment. 

2. A method as in Claim 1 further comprising: 

creating a first execution environment object including said second binary specification. 

50 

3. A method as in Claim 2 further comprising: 

creating a second execution environment object including said first binary specification. 

4. A method comprising: 

55 

generating a binary specification object for a first execution environment; 
generating a binary specification object for a second execution environment; and 
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generating a bridge object wherein said bridge object is used in mapping objects from said second execution 
environment to said first execution environment. 

5. The method of Claim 4 further comprising: 

5 using said bridge object to generate a proxy wrapping an interface in said second execution environment. 

6. A method for using functionality in a second execution environment in a first execution environment comprising: 

calling a method in a proxy interface in said first execution environment; and 

10 

converting said method call by said proxy interface to a corresponding method call for execution in said second 
execution environment. 

7. The method as in Claim 6 further comprising: 

*5 dispatching said corresponding method call for execution in said second execution environment to said second 

execution environment by said proxy interface. 

8. The method of Claim 6 where said converting said method call further comprises: 

using a type description to convert parameters from said first execution environment to said second execution 
20 environment. 

9. The method of Claim 7 further comprising: 

executing said corresponding method call in said second execution environment, and returning results of said 
execution to said proxy interface. 

25 

1 0. The method of Claim 9 further comprising: 

using a type description to convert said returned results from said second execution environment to said first 
execution environment. 

30 11. The method of Claim 6 wherein said second execution environment is a C++ programming language execution 
environment. 

12. A method for using functionality in a second execution environment in a first execution environment comprising: 

35 calling a method in a proxy interface in said first execution environment; 

converting said method call by said proxy interface to a corresponding method call for execution in said second 
execution environment, wherein said converting said method call comprises: 

using a type description to convert parameters from said first execution environment to said second execution 
40 environment; and 

dispatching said corresponding method call for execution in said second execution environmentto said second 
execution environment by said proxy interface. 

45 13. The method of Claim 12 further comprising: 

executing said corresponding method call in said second execution environment, and returning results of said 
execution to said proxy interface. 

14. The method of Claim 13 further comprising: 

50 using a type description to convert said returned results from said second execution environment to said first 

execution environment. 

1 5. A computer program product comprising computer program code for a method for enabling a first software program 
using a first binary specification in a first execution environment to employ a limited functionality of a second 

55 software program using a second binary specification in a second execution environment, the method comprising: 

creating a bridge in said first execution environment; and 
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creating, in said first execution environment using said bridge, a proxy wrapping an interface to said limited 
functionality of said second software program in said second execution environment. 

1 6. The computer program product of Claim 1 5 wherein said method further comprises: 
creating a first execution environment object including said second binary specification. 

17. The computer program product of Claim 1 6 wherein said method further comprises: 
creating a second execution environment object including said first binary specification. 

18. A computer program product comprising computer program code for a method for using functionality in a second 
execution environment in a first execution environment, said method comprising: 

calling a method in a proxy interface in said first execution environment; and 

converting said method call by said proxy interface to a corresponding method call for execution in said second 
execution environment. 

19. The computer program product of Claim 1 8 wherein said method further comprises: 

dispatching said corresponding method call for execution in said second execution environment to said second 
execution environment by said proxy interface. 

20. The computer program product of Claim 1 8 wherein said method further comprises: 

using a type description to convert parameters from said first execution environment to said second execution 
environment. 

21 . The computer program product of Claim 1 9 wherein said method further comprises: 

executing said corresponding method call in said second execution environment, and returning results of said 
execution to said proxy interface. 

22. The computer program product of Claim 21 wherein said method further comprises: 

using a type description to convert said returned results from said second execution environment to said first 
execution environment. 

23. A computer storage medium having stored therein a structure comprising: 
a binary specification for an execution environment including: 

a simple common identity structure. 

24. The computer storage medium of Claim 23 wherein said binary specification further comprises: 
an extended environment structure. 

25. The computer storage medium of Claim 23 wherein said simple common identity structure includes: 
a type name. 

26. The computer storage medium of Claim 23 wherein said simple common identity structure includes: 
a method acquire. 

27. The computer storage medium of Claim 23 wherein said simple common identity structure includes: 
a method release. 

28. The computer storage medium of Claim 24 wherein said simple common identity structure includes: 
a pointer to said extended environment structure. 

29. A method for enabling a first software program using a first binary specification to employ a limited functionality of 
a second software program using a second binary specification, including the following steps: 

a) initiating the creation of a stub, which is able to transform commands relating to said limited functionality of 
said second software program between said second binary specification and an intermediate binary specifi- 
cation, using a second bridge, wherein said second bridge provides a mapping of said second binary speci- 
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fication and said intermediate binary specification, 

b) initiating the creation of a proxy, which is able to transform commands relating to said limited functionality 
of said second software program between said first binary specification and said intermediate binary specifi- 
cation, using a first bridge, wherein said first bridge provides a mapping of said first binary specification and 
said intermediate binary specification, and 

c) initiating the arrangement of said proxy and said stub relatively to said first software program and said 
second software program in a manner allowing said first software program to employ said limited functionality 
of said second software program. 

30. A method for employing a limited functionality of a second software program using a second binary specification 
by a first software program using a first binary specification, including the following steps: 

a) initializing said limited functionality of said second software program by said first software program, 

b) creating a stub, which is able to transform commands relating to said limited functionality of said second 
software program between said second binary specification and an intermediate binary specification, using a 
second bridge, wherein said second bridge provides a mapping of said second binary specification and said 
intermediate binary specification, 

c) creating a proxy, which is able to transform commands relating to said limited functionality of said second 
software program between said first binary specification and said intermediate binary specification, using a 
first bridge, wherein said first bridge provides a mapping of said first binary specification and said intermediate 
binary specification, 

d) transmitting an command relating to said limited functionality from said first software program to said proxy, 

e) transforming said command from said first binary specification into said intermediate binary specification 
by said proxy, 

f) transmitting said command transformed by said proxy from said proxy to said stub, 

g) transforming said transmitted command from said intermediate binary specification into said second binary 
specification by said stub, 

h) transmitting said command transformed by said stub from said stub to said second software program, 

i) carrying out said command in said second software program and generating a response for said first software 
program, 

j) transmitting said response, being in said second binary specification, from said second software program 
to said stub, 

k) transforming said response from said second binary specification into said intermediate binary specification 
by said stub, 

I) transmitting said response transformed by said stub from said stub to said proxy, 

m) transforming said response from said intermediate binary specification into said first binary specification 
by said proxy, 

n) transmitting said response transformed by said proxy from said proxy to said first software program. 

31. A method for using a stub, which is able to transform commands relating to a limited functionality of a second 
software program between a second binary specification and an intermediate binary specification, using a second 
bridge, wherein said second bridge provides a mapping of said second binary specification and said intermediate 
binary specification, for enabling a first software program using a first binary specification to employ said limited 
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functionality of said second software program by further using a proxy, which is able to transform commands 
relating to said limited functionality of said second software program between said first binary specification and 
said intermediate binary specification, using a first bridge, wherein said first bridge provides a mapping of said first 
binary specification and said intermediate binary specification, wherein said proxy and said stub are arranged 
5 relatively to said first software program and said second software program in a manner allowing said first software 

program to employ said limited functionality of said second software program. 

32. A method for using a proxy, which is able to transform commands relating to said limited functionality of said second 
software program between said first binary specification and said intermediate binary specification, using a first 

10 bridge, wherein said first bridge provides a mapping of said first binary specification and said intermediate binary 

specification, for enabling a first software program using a first binary specification to employ said limited function- 
ality of said second software program by further using a stub, which is able to transform commands relating to a 
limited functionality of a second software program between a second binary specification and an intermediate 
binary specification, using a second bridge, wherein said second bridge provides a mapping of said second binary 

15 specification and said intermediate binary specification, wherein said proxy and said stub are arranged relatively 

to said first software program and said second software program in a manner allowing said first software program 
to employ said limited functionality of said second software program. 

33. A method according to any of the claims 29 - 32, wherein said creation of said stub is carried out in response to 
20 a loader function for said second software program. 

34. A method according to any of the claims 29 - 33, wherein said creation of said proxy is carried out in response to 
a function of said first software program. 

25 35. A method according to any of the claims 29 - 34, wherein said creation of said stub is carried out by a sub-program 
of the second software program. 

36. A method according to any of the claims 29-35, wherein said creation of said proxy is carried out by a sub-program 
of the first software program. 

30 

37. A method according to any of the claims 29 - 36, wherein said bridges are selected by a tool for selecting the 
desired bridge. 

38. A method according to any of the claims 29 - 37, wherein said mappings are selected by a function for selecting 
35 the desired mapping of the bridge. 

39. A method according to any of the claims 29 - 38, wherein said limited functionality is described by types. 

40. A method according to claim 39, wherein the types are stored in a type repository. 

40 

41 . A method according to claim 40, wherein the types are stored in said type repository along with the corresponding 
description. 

42. A method according to claim 40 or 41 , wherein a application program interface of said type repository is c-style. 

45 

43. A method according to any of the claims 29 - 42, wherein said first binary specification and said second binary 
specification are denominated by a string. 

44. A method according to any of the claims 29 - 43, wherein an interceptor is arranged between said proxy and said 
50 stub in order to intercept some of said commands. 

45. A method according to any of the claims 29 - 44, wherein said stub is able to transform all commands transmitted 
by the proxy by employing one dispatch mechanism. 

55 46. A computer program for carrying out a method according to any of the claims 29 - 45 on a computer system. 

47. A data carrier for storing a computer program for carrying out a method according to any of the claims 29 - 45 on 
a computer system. 
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48. A method for using a computer system for carrying out a method according to any of the claims 29 - 45. 

49. A computer system comprising a storage medium on which a computer program for carrying out a method accord- 
ing to any of the claims 29 - 45 or 48 is stored. 
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struct unoEnvironment 

{ 

/** a name for this environment 

*/ 

rtlString * pName; 

/** A free context pointer, that can be used for specific classes of environments, e.g. 
ajvm pointer 

*/ 

void * pContext; 
/** Acquires this environment. 

@param pEnv this interface 

*/ 

void (SAL CALL * acquire)( unoJEnvironment * pEnv ); 
/** Releases this environment; Last release of environment revokes the environment 
from runtime. 

@param pAccess this access interface 

void (SAL_CALL * release)( uno Environment * pEnv ); 
/** Tests if two environments are equal. 

@param pEnvl one environment 
@param pEnv2 another environment 

*/ 

sal Bool (SAL CALL * equals) ( const uno_Environment* pEnvl, const 
uno Environment * pEnv2 ); 

/** 

* You register internal and external interfaces via his method. Internal interfaces are 
proxies that are used in an environment. External interfaces are interfaces 
that are exported to another environment, thus providing an object identifier 
for this task. This can be called an external reference. Interfaces are held 
weakly at an environment; they demand a final revokeInterface()call for each 
interface that has been registered. 

@param pEnv this environment 

@param pplnterface inout parameter for the registered interface 
@param ppOId inout parameter for the corresponding object id 
@param pTypeDescr type description of interface 
@param acquire function to acquire an interface; this function 

provides a boolean return value to signal if the acquisition was 
successful (necessary for proxy interfaces) 



/** 



void (S AL CALL * registerlnterface) (uno Environment * pEnv, void ** 
pplnterface, rtl_String ** ppOId, typelib lnterfaceTypeDescription 
*pTypeDescr, uno regAcquireFunc acquire ); 

ANY interface that has been registered is revokeed via this method. 
@param pEnv this environment 
@param pOId object id of interface to be revoked 
@param pTypeDescr type description of interface to be revoked 

void (SAL_CALL * revokelnterface) ( uno Environment * pEnv, rtl String * 
pOId, typelib lnterfaceTypeDescription * pTypeDescr ); 

Fig. 3 A 
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/** Retrieves an interface identified by its object id and type from this environment. 
@param pEnv this environment 

@param pplnterface inout parameter for the registered interface; (0) if 

none was found 
@param pOId object id of interface to be retrieved 
@param pTypeDescr type description of interface to be retrieved 

*/ 

void (SALCALL * getRegisteredlnterface) ( unoEnvironment * pEnv, void 
** pplnterface, rtlString * pOId, typelib lnterfaceTypeDescription * 
pTypeDescr ); 

/** 

Retrieves the object identifier for a registered interface from this environment. 
@param pEnv this environment 

@param ppOId inout parameter for object id of interface; (0) if none 

was found 
@param plnterface a registered interface 
@param pTypeDescr type description of interface 

*/ 

void (SAL CALL * getRegisteredObjectldentifier) ( uno Environment * 
pEnv, rtl String ** ppOId, void * 

pInterface,typelib_InterfaceTypeDescription * pTypeDescr ); 

/** 

* Disposing callback function pointer that can be set to get signalled before the 

environment is destroyed. 

@param pEnv environment that is being disposed 

*/ 

void (SALCALL * environmentDisposing) ( uno_Environment * pEnv ); 

* Computes an object identifier for the given interface; is called by the environment 

implementation. 

@param pEnv corresponding environment 
@param ppOId out param: computed id 
@param plnterface an interface 

*/ 

void (SAL CALL * computeObjectldentifier) ( uno Environment * pEnv, 
rtl String ** ppOId, void * plnterface ); 
/** Function to acquire an interface. 

@param pEnv corresponding environment 
@param plnterface an interface 

*/ 

void (SAL CALL * acquirelnterface) ( uno Environment * pEnv, void * 
plnterface ); 

/** 

* Function to release an interface. 

@param pEnv corresponding environment 
@param plnterface an interface 

*/ 

void (SALCALL * releaselnterface) ( unoEnvironment * pEnv, void * plnterface 

}' ^ 

. Fig. 3B 
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